[greatgib]

In my opinion, graphql is a good detector of companies that want to be "cool" and thinks that they do software well as they follow dogmatically things like clean code. But that are not pragmatic and so they don't realize the bad side effects of it. Often early stage startups.

Graphql is a typical example of something that is nice on paper but doesn't pass the reality check.

[satvikpendem]

It does, but only if you use it as intended, ie with Relay: https://alan.norbauer.com/articles/relay-style-graphql

Otherwise, yes, it's not better than REST.

[cyanydeez]

Explain whether you're cynical on the frontend or backend

[precommunicator]

"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.

[NhanH]

Don’t build a generic API for your specific interface.

Unless you have hundreds or thousands of developers consuming an API endpoint, it’s generally better to build the API tailor specifically for each screen/ use cases/… you have. When thinking about API that way, the value of graphql is not that clear anymore

[gorjusborg]

I considered graphql recently and selected against it. I am not saying graphql is bad, but it was not as good for our situation.

Graphql is really suited for aggregating disparate data sources and making them look unified. You dont need to use ot that way, but that is the main value prop.

The downsides that killed it for us was that performance characteristics seemed less clear, and ever replacing it would be a nightmare due to its unstructured usage.

Things that were simple in REST (like rate limiting, capacity planning, authorization) seemed more difficult, and we didn't need the killer feature of it.

It is an interesting tech, but you are probably better off starting with REST and adopt gql on top afterward if you need it.

[nullxone]

Thanks. A lot of these things ring true in a very practical sense.

GraphQL keeps getting more mature and adding more and more tooling/features/middleware, but we also need to work on de-risking the technology from a more fundamental perspective to get to a rock solid foundation.

[greatgib]

For example, one promoted advantage of graphql is to be able to be more efficient by only requesting fields that you really need.

But the reality is that it is often more costly to parse exactly what the client want and have graphql retrieve the whole data and decimate just the needed fields. And you don't even save bandwidth because a lot of metadata had to be transferred to do that.

In a similar way, you will do one request, and the graphql server will have to trigger n requests to internal services. Then you have things like having to wait for the slower service to be able to reply and display anything to the user, also having to still send n internal requests even if one of the first and important one would fail, like retrieving an user account.

It will be harder to cache responses if the response content is specific to each request.

A lot of things like that, where, in the end, you see that it is a lot more easier and efficient to have the client do generic individual api requests.

[ipaddr]

Why?