Doing graphql requests server side

[aszenz]

While building server side rendered pages, it is faster to preload data from the api and use it in html templates.

Is there a way to pass a graphql query server side and get data, that can then be used for building a view.

[oojacoboo]

@aszenz You certainly could use your operations for internal use. But, I can't help but think this is a bad idea, unless you're only talking about a handful of highly optimized pages for a high-traffic application. In general, the tech debt created from something like this is going to be a net negative and something you regret doing.

That said, there are many ways to approach this. Firstly, operations (queries and mutations) in GraphQLite are just methods of a "controller". Instantiate the "controller" class and call the operation method, pass the input type object, or whatever fields to the method. From there you have the response data. The relations will be available, just like a GraphQL request when building out a query. You'll just use them within PHP to make method calls. If, for some reason, you want an array response of structured data, like you'd get from an actual HTTP response, just mock a request object and pass it into the GraphQLite middleware.

As for the HTML rendering. I have no idea how you would plan on managing this, in additional to a frontend implementation. There are obviously ways of doing it, but it's not going to be ideal, especially if you're using a component architecture framework, like React, Vue, Angular, etc.

[aszenz]

I'm curious as to why you think it will create tech debt.

The approach u have outlined is definitely an option, especially creating the mock request object.

As for html, it is quite simple, i can pass the data inline with html to any front end framework. This way i avoid several loading states in my apps.

My original reason to create the issue was to see doing server side requests is a feature graphqlite would support.
Concretely i should be able to pass a real request object (from symfony, laravel or psr) and receive a structured response without it being emitted.

[oojacoboo]

Well, it creates tech debt b/c it's one more thing you have to manage and you're essentially replicating existing functionality, only for some marginal performance increases, or usability improvements - marginal, and increasing more marginal as HTTP2 adoption, internet speed improvements, etc.

It makes sense on some apps, don't get me wrong. I'd say it's a waste of time on 90% though. That's my opinion.

You're going to have to manage your HTML on the server-side and then manage/replicate the exact same HTML on the frontend. Then, you're going to have to manage to keep them in sync, so random little things don't get out of sync... Sounds like a disaster to me. IMO, if you cannot find a way to share the exact same HTML between the server-side with PHP and the frontend with JS, I would only do this if absolutely necessary.

[aszenz]

You're going to have to manage your HTML on the server-side and then manage/replicate the exact same HTML on the frontend

Normally this is useful to preload data for an app, by storing it inline.

But you could certainly build html too, but as you said that can be hard to keep in sync. Although that is also a nice idea for static pages where you don't even need a js framework.