A question you should ask yourself at the start that I rarely here any discussion of: how much do you want to expose your backend data model to your front end(s)?<p>If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details.<p>If the answer is "not at all" then GraphQL is probably going to be a bad idea because that is the whole point of GraphQL.<p>The reason people don't realize this is because sadly most people's idea of a REST API is already just a plain 1-1 mapping from DB tables to JSON objects served over HTTP. If you're doing that, you're already coupling any front ends or other consumers to your data model, so what do you have to lose with GraphQL (other than the complexity of deploying it)?<p>When REST was coined the goal was to hide as much data model stuff as possible. This is really really important if your backend app needs a high degree of interoperability across organizational boundaries, because data migration is hard! But if your API is consumed only by a small number of components that your organization has total control over, you might not care that much.<p>Years ago I used to see people implementing crude remote procedure call patterns over HTTP because they thought that's what REST was, and had been told it was better because of reasons. But this wasn't a better way of doing remote procedure calls. It was a much worse way! Now I see people using frameworks that just expose all their DB models as HTTP endpoints because they think that's what REST is and have been told it's better. That isn't really what REST is, and GraphQL might be a better way of doing that if that's what you need.<p>REST is a bunch of constraints that make interoperability and scalability easy to achieve. Maybe you benefit from those constraints and maybe you don't. But that's what you need to think about before you think about GraphQL.
My conclusion is that there isn't much value in evaluating 1000s of perspectives, they're the same exact arguments you'd find in any blog or technical documentation comparing the two.
I’m surprised no one has mentioned the obvious interest of the author working for a company that provides REST tooling, reaching the conclusion that REST is a better option.
Personally I found GraphQL to be a God-sent for prototyping. Tools such as Hasura and postgraphile are just amazing to whip out fully-working backend very quickly. I do agree with some of the posts though about security being a bit of a hassle. It's not impossible to secure GraphQL endpoints (e.g. through row-level or column-level security for Postgres-based backend) but it's not as straight-forward as securing REST endpoint.
Regarding the “it’s not worth the extra complexity” argument, I think it depends on how you’re creating your GraphQL server. If you’re writing the server logic yourself, I think GraphQL is absolutely not worth the extra complexity. Making a REST server is way easier than making a GraphQL server.<p>But I think the balance can tip in favor of GraphQL if you’re using a managed GraphQL server like Hasura. I’m using Hasura for a solo project and I actually find it simpler than maintaining my own REST API code. All I need to do is specify my data model and never need to write any boiler plate for new endpoints. I know there are similar services for REST that can automate the boiler plate code away (like Supabase). But Hasura automates away the hard parts of GraphQL, and I prefer the experience as a client of GraphQL over REST. I like being able to specify exactly what data I want from the API and being able to get values for foreign tables in one query without needing to join the data client-side.
1. Apples vs Oranges: GraphQL is a protocol with an open spec, REST is an architectural style.<p>2. Nevermind how good or a bad GraphQL is, the de-facto standardization provides lots of benefits, in the same way as Docker did for containers.<p>3. GraphQL complexity is mostly an essential complexity in software engineering, with a bit of accidental complexity due to novelty and unaddressed problems/missing features.<p>4. GraphQL allows better modeling of the domain. It fits well to use with DDD/CQRS/ES/Sagas/Persistence Ignorance/TBUIs[1]. If all you need is a generic app managing a tabular collections of items, then you can use generic architectural styles like CRUD/REST/RDBMS/ACID transactions/ORM/generic Web Admin UIs, either coded manually, using AI copilots, nocode, or lowcode tools like Hasura or PostGraphile.<p>---<p>[1] Domain Driven Design, Command-Query Responsibility Segregation, Event Sourcing, Task-Based or Task-Driven UIs
After 15 years of heavy restful API usage, building 10 restful API’s, using the GitHub and Shopify GraphQL API’s and providing our own GraphQL API in PHP, I think this article puts the nail on the head.<p>It is nice to only get the data you need as a client. The Graphiql explorer is very nice to try to get the right data. But that is mainly an advantage if the restful endpoints are badly designed. The Shopify API around inventory is very bad and became worse over time. You would need 15-20 rest requests or 1 complicated Graphql request to get the 3 fields you need together. But in most cases, even as a front end user, if the API is designed nicely it is not worth the complicated whole of the system of Graphql.<p>GitHub’s API works better as rest then as Graphql in my opinion. And the Stripe API is also very nice. I don’t need Graphql there as a user.
My main takeaway: GraphQL moderately improves developer enjoyment (DevEx) by majorly increasing the cost of making production ready APIs.<p>I've worked on bigger teams where the job was boring and there was plenty of spare capacity to improve DevEx. Spending a lot for a more enjoyable DevEx was worth it to retain good talent. They typically spent about 50% of their total capacity on DevEx and technical debt. Those teams would probably benefit a lot from GraphQL.<p>Other projects it's just me building an entire product with extremely tight timelines. Or it's a small team without a lot of spare capacity. I probably won't elect to use GraphQL in that situation.
It comes down to the right tool for the job. But the problem comes from scaling. I worked at a place that was using REST apis, but when they grew, they needed lots of bundling (or filtering down of excess data)d. Graphql gets bundling for almost free. While not unique, it also couples dataloaders, which essentially caches api calls on the request level.<p>Good ideas, but extra features require extra implementation.
One problem I’ve seen is graphql comes over for some high profile project needs. It feels elegant to get the fields you want in the way you want them.<p>The trouble comes when REST API parity is not maintained.<p>The dev experience then becomes an O(N) search through the autogenerated graphql docs to determine X is missing and the thing you are trying to do can’t be done elegantly.
We found that allowing the FE guys to iterate faster over relatively simple data models was worth the extra backend complexity. Additionally, every time a JSON deserialisation fails because someone typo'd a key an angel loses its wings, so that's nice to avoid.
Given the complexity vs DX trade off with GraphQL presented in the post: perhaps GraphQL goes the way of SQL.<p>SQL is a phenomenal API but nobody builds a “sql api server” at work.<p>People do build products that present a sql api, because it’s a great API.
GraphQL makes front end work easier because FE folks can't seem to handle the complexity involved in making multiple calls to a backend. GraphQL moves that complexity somewhere else (ie: the backend).<p>From a BE POV GraphQL makes things more difficult because the failure behavior is more complicated. If a failure occurred in the FE then the FE presumably knows what to do. If a failure occurs in a graphql call chain it's unclear what the FE would like to happen, and the FE developer is probably clueless as to what they want, since the structure has been abstracted away.
Amazing findings! Really admire your effort here<p>Btw. If you're building a GraphQL API using TypeScript, you should take a look at garph (<a href="https://garph.dev" rel="nofollow noreferrer">https://garph.dev</a>) which helps you to create type-safe GraphQL APIs without code-gen