[hderms]

In my relatively naive opinion, graphql exists to solve a few things (which are mostly benefits for large scale companies):

1. Reduce the total number of HTTP connections required to get the data for a specific component or page. Imo this is presumably less important with http3 but the driving force is probably similar for both.

2. Give backend-for-frontend style services more autonomy to provide an interface that works for a specific feature on the front end without coupling it to specifics of how the backend organizes resources

3. Allow performance issues with frontend query logic to be addressed without changing anything on the front end

I think the situations where it would be useful are large teams that want to operate more independently where the overhead of dealing with graphql is worth it.

An example being someone trying to render a component for a list of comments. It would be great if the front end could just write some "magic" query that gives them everything they want and they don't have to worry about batching requests to specific endpoints and the order in which they should make those requests. That doesn't mean the problem magically goes away, but it's now someone else's problem and that's good: the app development can free itself from things it shouldn't care about.

[andyfleming]

I think you've got number 3 backwards. GraphQL is a generic query solution that is harder to optimize than an endpoint that was built as a one-off for a front-end use case. Endpoints designed to support a specific UI view or operation are easy to optimize because their use case is narrow and the queries can be modified simply and safely. There might be more ceremony, but it's much more maintainable in my opinion.

[hderms]

Graphql servers are typically not run in a manner that allows arbitrary query execution, usually only a select set of queries that were written by the devs, tested, and potentially profiled before deployment. from that perspective, if a mobile client is written to work against the interface they provide, then if you need to fix things on the backend, you can potentially do so without the frontend being aware of it. In that sense it's the same thing as a specifically designed REST endpoint, so I'll give you that, but it's hardly a negative in GraphQL's favor.

[mmcnl]

Number 1 is valid. But becoming less relevant as you mentioned. Number 3 also valid.

Number 2 I really doubt this. Having more flexible API contracts (GraphQL) usually only makes dependencies worse, not less. Sure you can write any query you want, but how do you agree on expectations if there is no contract on the API level? Strict API contracts usually force you up-front to agree on expectations.

[hderms]

I probably wasn't entirely clear in my post that I'm not necessarily a believer in GraphQL. I'm mostly repeating/surmising the reasons that other people are interested in it, and not necessarily myself. You could argue with any of the points, really.

[pier25]

Yes 100%

GraphQL solves these issues but it also has a cost that only makes sense when the team/project is large enough.

[oxff]

It is a good summary, I would also add the need for combining lots of internal badly documented microservices as a prerequisite (basically what they used it originally for in Facebook)