Server side functionality

[Lutymane]

A dedicated discussion in continuation to #1

[etareduction]

@Lutymane Tell me if you need me to document something in the backend codebase, explain or point out.

EDIT: I think first of all this weekend I'll add a readme with explanation of authentication flow (which backend endpoint to direct user to)

You can currently see authentication example on / and API documentation on /graphiql routes of backend server. The API itself is at /graphql.

[Lutymane]

@etareduction I would much appreciate if you could perhaps implement client-side APIs to communicate with backend, so I could use them on frontend without diving into details for now.

We could have a folder /api/ with all the interfaces, which would be functions smth like
export const shareShader = async (code: string, ...) : IShareShaderResult => { ... }

[etareduction]

Noice. But how to handle parent shader?

You can pass parentId as an optional parameter to the shareShader mutation. I can host the server for you on my domain if you don't want to spin up the container yourself right now. On a running server, you can see all the types in schema on /graphiql (notice the i in it)

So in high-level overview, to create a shader with parent you would first fetch a list of shaders, the user would choose one of them to create a revision and then you pass an id of that shader to shareShader mutation.

[Lutymane]

It's just I don't have much time for this project for now. Could you elaborate why user needs to fetch a list of shaders? Also does sharing require to be logged in into GH?

[etareduction]

It's just I don't have much time for this project for now. Could you elaborate why user needs to fetch a list of shaders? Also does sharing require to be logged in into GH?

It's a simple flow, user first has to see the shader he's creating a revision for - and use it's id as parentId. User could also acquire this id by navigating to a link that contains it, like https://glsl.app/shaders/tz4a98xxat96iws9zmbrgj3a. (it has to be implemented on the frontend, i'm talking about slug page)

shareShader doesn't require authentication and is intended for anonymous sharing by link. publishShader does require authentication and creates a shader with author field populated. In a public shader gallery we would display only shaders that have authors (so are published).

[Lutymane]

If user publishes own shader, their address bar will change to the generated link, same goes when someone creates a child shader, they should first open the link, so ID is always out there.

Also I kinda reconsidered the idea about revisions, since we already have parent/child relation, that'll be enough to handle same shader changes.

So I guess for now it's enough to implement anonymous sharing of shaders? That's why I asked about implementing some API for backend, so I could just use provided TS function async shareShader(code, parent?, captcha): ShaderID without diving into GQL for now. Also I don't really see any point of using Vue specific library for GQL?

The backend needs to verifiy some captcha to protect against spammers, as well. I used invisible recaptcha2 before, but we could try smth else like Cloudflare Turnstile?

[etareduction]

If user publishes own shader, their address bar will change to the generated link, same goes when someone creates a child shader, they should first open the link, so ID is always out there.

Yes, we would use listing of shaders later, for the gallery functionality.

So I guess for now it's enough to implement anonymous sharing of shaders? That's why I asked about implementing some API for backend, so I could just use provided TS function async shareShader(code, parent?, captcha): ShaderID without diving into GQL for now. Also I don't really see any point of using Vue specific library for GQL?

You would need a library with reactive queries and normalized cache for good user experience overall. Right now i see it's usage primarily for the loading spinners and pagination in the shader gallery. But there is no point of doing data fetching some other way now and then adding this library when we start implementing gallery functionality.

As i said earlier, with the help of client library and typed document generator, there is no need in abstracting queries furthermore. The only thing you would need to do is write some .graphql files with queries. I can do this for you as well as setting up urql and gqlgen if i could find some free time for that before you do.

The backend needs to verifiy some captcha to protect against spammers, as well. I used invisible recaptcha2 before, but we could try smth else like Cloudflare Turnstile?

Yeah, it seems like a valid concern. I'll look into it.

[etareduction]

@Lutymane Here you can check out the schema and do some test queries: https://glslapp.gamerzero.dev/graphiql

Currently you'd have to login using github first to access it (I've locked the /graphiql endpoint behind auth accidentally)

Also I've figured out some problems with deployment and would open a PR that fixes them soon.

[Lutymane]

I can't find where do I log in?

[etareduction]

I can't find where do I log in?

Github login link is on the / page.

[Lutymane]

Tested it a lil, everything works nicely. But is there log out button?

[etareduction]

Tested it a lil, everything works nicely. But is there log out button?

Not at the moment, but it would be easy to add. Do you prefer having a url on backend which does the logout and redirects back to some page in the app or a graphql mutation that would just clear token cookie and leave the rest of the work on frontend?

[Lutymane]

Graphql mutation would be cool, so we won't have to reload anything. But having a url is the easiest, so let's stick to that