6 ms·

I reviewed 1,000s of GraphQL vs. REST perspectives

70 points by dphuang2 3y ago

injb 3y ago
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)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. 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. 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)? 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. 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. 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.
- plumeria 3y ago
  I'm somewhat confused about what you mean by "expose your backend data model to your front end(s)", since you can disable introspection in production.
  - injb 3y ago
    The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.
    - patrickthebold 3y ago
      My understanding is "arbitrary queries" <> "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.) What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST world into a single request.
      - injb 3y ago
        Thanks, that's a more nuanced understanding of it than I had. Still, when I try to think about keeping that model in sync with the real underlying model, it scares me. It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.
        pests 3y ago
        GraphQL exposes your backend model the same way your json response to a REST api exposes the backend model - they dont. It's up to your REST api to assemble data from the database (or elsewhere) and return them in a structured format. GraphQL resolvers do the same. You can hit another API, query a database, or return file data. It's up to you what you want each field to resolve to.
- silisili 3y ago
  I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns. I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for. I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.
  - cheald 3y ago
    Interestingly, the principle of single responsibility is specifically why I like GraphQL over REST. As your frontend complexity grows, your REST payloads tend to become carefully-balanced collections of complex shapes, and it becomes very difficult to maintain and refactor over time. In GQL, by comparison, each field or mutation has its own isolated implementation, authorization is handled at a granular level, and frontend queries can evolve as needed without imposing any significant need for changes on the backend. REST is great for small, compact APIs which serve a couple of views, but as the product grows in scope and complexity, GraphQL ends up feeling significantly easier to keep straight. The other thing is that it's very easy to build "complex" REST APIs on top of GraphQL - execute an internal query, reshape the result into a JSON payload to conform to the REST contract - but implementing GraphQL on top of a bunch of REST calls is a lot hairier. GraphQL feels more like a set of primitives, while REST is a coalesced interface.
  - ttfkam 3y ago
    Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.
    - fswd 3y ago
      writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years. And with postgraphile, and a remix/next BFF, you don't even need a backend!
- mikecaulley 3y ago
  How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.
- semiquaver 3y ago
  It’s very much possible to keep your backend data model from leaking too much into your GraphQL schema, it’s just more work than for example using some kind of generator that creates a GraphQL schema from your database schema. The harder thing in my experience is to make a GraphQL API that is performant across all edge cases and properly cost-limited. That takes an enormous amount of internal analytics infrastructure and work and is often not worth the effort. And after all that effort, integrators don’t usually want to take the trouble to learn enough GraphQL to actually use the API. I’ve come to the conclusion that GraphQL is a pretty good system for internal APIs for web and mobile, but a pretty poor one for public-facing APIs.
- windexh8er 3y ago
  Happened to have worked with an API security product for a while that was sitting in front of a lot of large brands. One retailer that had APIs constantly under attack from bot and organized crime invested a lot of time and money into remapping their old rest API such that they could better protect the pieces of it in different ways. Then, out of the blue, we learned they were moving everything to GraphQL because they had done cost analysis on how many fewer calls they'd need to make, creating efficiency gains of over 50% of all session transactions. What they failed to take into account was that all of the time and money invested in the prior methods to protect really relied on the structures of their REST schema. Now everything would need to build back up and many of the security introspection gates were within the chaining of the REST calls which could no longer happen.
- ttymck 3y ago
  This explanation is evident of a lack of understanding. I should know, because I felt exactly the way you do before I implemented a GraphQL server. Unfortunately, I still don't know how to explain in words why your understanding is inaccurate, I only know how what it means in practice, by example. GraphQL is still elusive in that regard.
adamredwoods 3y ago
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. Good ideas, but extra features require extra implementation.
cameronfraser 3y ago
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.
- appplication 3y ago
  I actually found this very helpful. There’s so much cruft and bullshit and promotion among web frameworks and tech, it’s difficult to get a sense of what is the right decision if you’re new to web dev.
deleted 3y ago
[deleted]
nesarkvechnep 3y ago
Are we talking about REST with HATEOAS? If we are, it’s apples to oranges.
ushakov 3y ago
Amazing findings! Really admire your effort here Btw. If you're building a GraphQL API using TypeScript, you should take a look at garph (https://garph.dev https://garph.dev) which helps you to create type-safe GraphQL APIs without code-gen
anotherhue 3y ago
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.
tango12 3y ago
Given the complexity vs DX trade off with GraphQL presented in the post: perhaps GraphQL goes the way of SQL. SQL is a phenomenal API but nobody builds a “sql api server” at work. People do build products that present a sql api, because it’s a great API.
cmgbhm 3y ago
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. The trouble comes when REST API parity is not maintained. 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.
ajjenkins 3y ago
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. 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.
blacksoil 3y ago
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.
- flagged24 3y ago
  If you consume your own graphql endpoint you can add some layer of security by only allowing predefined queries and inspect the provided query variables. I use PostGraphile as an Express middleware and only allow whitelisted requests.
- zifeo 3y ago
  That's the reason we have developed field-level access control [1] with policies on the top of rating-limiting [2] for Metatype. [^1] https://metatype.dev/docs/tutorials/policies-and-materializers#policy-based-access-control-pbac https://metatype.dev/docs/tutorials/policies-and-materialize... [^2] https://metatype.dev/docs/tutorials/authentication-and-security#rate-limiting https://metatype.dev/docs/tutorials/authentication-and-secur...
nivertech 3y ago
1. Apples vs Oranges: GraphQL is a protocol with an open spec, REST is an architectural style. 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. 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. 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. --- [1] Domain Driven Design, Command-Query Responsibility Segregation, Event Sourcing, Task-Based or Task-Driven UIs
casperb 3y ago
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. 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. 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.
karmajunkie 3y ago
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.
- dphuang2 3y ago
  We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me. Your observation is sort of the point of this article. Everyone has their opinion but nobody is de facto right.
  - nivertech 3y ago
    You should have put a proper disclosure in the post to avoid speculation. Also it seems off to do all this research, and then instead of summarizing it properly, throw evewrything away and finish it with your own sentiment. I remeber there was a paper where the reserches asked students to implement the same API using either REST/HTTP, or GraphQL, and the conclusion were in favor of GraphQL. I would've added reviews of the research papers on this subject, in addition to the social media posts. The former adding more rigor than the latter.
    - dphuang2 3y ago
      Fair points, I added a disclosure for clarity in future reference. That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting. Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.
      - nivertech 3y ago
        What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL. GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.
mannyv 3y ago
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). 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.
- DGCA 3y ago
  1. async/await is a thing. 2. The GraphQL spec tells you how errors should be handled.
JackMorgan 3y ago
My main takeaway: GraphQL moderately improves developer enjoyment (DevEx) by majorly increasing the cost of making production ready APIs. 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. 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.
- unusualmonkey 3y ago
  Depends how you use it. We use Hasura, and find this massively decreases the cost of making production ready API's vs traditional REST development.

70 points by dphuang2 3y ago

injb 3y ago

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)? If your answer is "completely", which it sometimes is, then GraphQL might be a good option. It's only a question of implementation details. 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. 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)? 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. 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. 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.

plumeria 3y ago
I'm somewhat confused about what you mean by "expose your backend data model to your front end(s)", since you can disable introspection in production.
- injb 3y ago
  The issue I'm talking about is allowing clients to make arbitrary queries via GQL. Maybe I've misunderstood it, but that's how I've seen it used before. If clients can do that, then they need to know about the model. And if they can't then I'm not sure what GQL does that REST doesn't do.
  - patrickthebold 3y ago
    My understanding is "arbitrary queries" <> "arbitrary _database_ queries". So you can have some abstract "graph" that can be queried, and separately implement "resolvers" (IIRC) that actually tie parts of the graph to actual queries. (So there is a layer of indirection.) What you get is a way for clients to tell you precisely what fields it needs and a way for it to coalesce what would be multiple api calls in a REST world into a single request.
    - injb 3y ago
      Thanks, that's a more nuanced understanding of it than I had. Still, when I try to think about keeping that model in sync with the real underlying model, it scares me. It sounds to me like there is still bound to be some correlation between querying flexibility on the client side, and coupling between the client and server. But that is OK in many cases and in fact is how many REST apis are already being implemented.
      - pests 3y ago
        GraphQL exposes your backend model the same way your json response to a REST api exposes the backend model - they dont. It's up to your REST api to assemble data from the database (or elsewhere) and return them in a structured format. GraphQL resolvers do the same. You can hit another API, query a database, or return file data. It's up to you what you want each field to resolve to.
silisili 3y ago
I've always found REST more logical. In a way, it's like the Unix philosophy...do one thing(at a time) and do it well. Implementing Graphql on the backend turns into a clusterf of spaghetti code real quick. And there are a lot of footguns. I've noticed a lot of frontend folks especially like GraphQL, as they just want the data in as few calls as possible, which I can't fault them for. I've read about an apollo bridge that basically does GQL over REST. I'm pretty curious how well that works, because it sounds like the best of both worlds. Clients who want GQL have it, clients that want REST have it, and backend logic itself is massively less complex.
- cheald 3y ago
  Interestingly, the principle of single responsibility is specifically why I like GraphQL over REST. As your frontend complexity grows, your REST payloads tend to become carefully-balanced collections of complex shapes, and it becomes very difficult to maintain and refactor over time. In GQL, by comparison, each field or mutation has its own isolated implementation, authorization is handled at a granular level, and frontend queries can evolve as needed without imposing any significant need for changes on the backend. REST is great for small, compact APIs which serve a couple of views, but as the product grows in scope and complexity, GraphQL ends up feeling significantly easier to keep straight. The other thing is that it's very easy to build "complex" REST APIs on top of GraphQL - execute an internal query, reshape the result into a JSON payload to conform to the REST contract - but implementing GraphQL on top of a bunch of REST calls is a lot hairier. GraphQL feels more like a set of primitives, while REST is a coalesced interface.
- ttfkam 3y ago
  Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.
  - fswd 3y ago
    writing graphql resolvers by hand was what I did in ... 2017. I've been using postgraphile since and couldn't be happier. I don't think I've written a single line of Apollo in 5+ years. And with postgraphile, and a remix/next BFF, you don't even need a backend!
mikecaulley 3y ago
How you model the data at rest does not need to match the GraphQL specification. The GraphQL specification should be similar to your REST entities but they have traversable edges to other entities.
semiquaver 3y ago
It’s very much possible to keep your backend data model from leaking too much into your GraphQL schema, it’s just more work than for example using some kind of generator that creates a GraphQL schema from your database schema. The harder thing in my experience is to make a GraphQL API that is performant across all edge cases and properly cost-limited. That takes an enormous amount of internal analytics infrastructure and work and is often not worth the effort. And after all that effort, integrators don’t usually want to take the trouble to learn enough GraphQL to actually use the API. I’ve come to the conclusion that GraphQL is a pretty good system for internal APIs for web and mobile, but a pretty poor one for public-facing APIs.
windexh8er 3y ago
Happened to have worked with an API security product for a while that was sitting in front of a lot of large brands. One retailer that had APIs constantly under attack from bot and organized crime invested a lot of time and money into remapping their old rest API such that they could better protect the pieces of it in different ways. Then, out of the blue, we learned they were moving everything to GraphQL because they had done cost analysis on how many fewer calls they'd need to make, creating efficiency gains of over 50% of all session transactions. What they failed to take into account was that all of the time and money invested in the prior methods to protect really relied on the structures of their REST schema. Now everything would need to build back up and many of the security introspection gates were within the chaining of the REST calls which could no longer happen.
ttymck 3y ago
This explanation is evident of a lack of understanding. I should know, because I felt exactly the way you do before I implemented a GraphQL server. Unfortunately, I still don't know how to explain in words why your understanding is inaccurate, I only know how what it means in practice, by example. GraphQL is still elusive in that regard.

adamredwoods 3y ago

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. Good ideas, but extra features require extra implementation.

cameronfraser 3y ago

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.

appplication 3y ago
I actually found this very helpful. There’s so much cruft and bullshit and promotion among web frameworks and tech, it’s difficult to get a sense of what is the right decision if you’re new to web dev.

deleted 3y ago

[deleted]

nesarkvechnep 3y ago

Are we talking about REST with HATEOAS? If we are, it’s apples to oranges.

ushakov 3y ago

Amazing findings! Really admire your effort here Btw. If you're building a GraphQL API using TypeScript, you should take a look at garph (https://garph.dev https://garph.dev) which helps you to create type-safe GraphQL APIs without code-gen

anotherhue 3y ago

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.

tango12 3y ago

Given the complexity vs DX trade off with GraphQL presented in the post: perhaps GraphQL goes the way of SQL. SQL is a phenomenal API but nobody builds a “sql api server” at work. People do build products that present a sql api, because it’s a great API.

cmgbhm 3y ago

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. The trouble comes when REST API parity is not maintained. 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.

ajjenkins 3y ago

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. 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.

blacksoil 3y ago

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.

flagged24 3y ago
If you consume your own graphql endpoint you can add some layer of security by only allowing predefined queries and inspect the provided query variables. I use PostGraphile as an Express middleware and only allow whitelisted requests.
zifeo 3y ago
That's the reason we have developed field-level access control [1] with policies on the top of rating-limiting [2] for Metatype. [^1] https://metatype.dev/docs/tutorials/policies-and-materializers#policy-based-access-control-pbac https://metatype.dev/docs/tutorials/policies-and-materialize... [^2] https://metatype.dev/docs/tutorials/authentication-and-security#rate-limiting https://metatype.dev/docs/tutorials/authentication-and-secur...

nivertech 3y ago

1. Apples vs Oranges: GraphQL is a protocol with an open spec, REST is an architectural style. 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. 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. 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. --- [1] Domain Driven Design, Command-Query Responsibility Segregation, Event Sourcing, Task-Based or Task-Driven UIs

casperb 3y ago

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. 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. 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.

karmajunkie 3y ago

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.

dphuang2 3y ago
We use GraphQL internally but I admit I am currently more biased towards REST after battling with GraphQL, building a OpenAPI-based company, and playing with ergonomic REST-based frameworks like FastAPI. I still think the GraphQL DX is still miles ahead of OpenAPI and I really admire the best practices in GraphQL prescribed by Relay. But right now, REST is king for me. Your observation is sort of the point of this article. Everyone has their opinion but nobody is de facto right.
- nivertech 3y ago
  You should have put a proper disclosure in the post to avoid speculation. Also it seems off to do all this research, and then instead of summarizing it properly, throw evewrything away and finish it with your own sentiment. I remeber there was a paper where the reserches asked students to implement the same API using either REST/HTTP, or GraphQL, and the conclusion were in favor of GraphQL. I would've added reviews of the research papers on this subject, in addition to the social media posts. The former adding more rigor than the latter.
  - dphuang2 3y ago
    Fair points, I added a disclosure for clarity in future reference. That being said, the Pro REST perspectives do scare me away from GraphQL in production. But seeing some posts about PostGraphile + Persisted Queries is interesting. Also, research papers would have been nice to address but I am satisfied with the many hours this took to compile. A future follow-up may be necessary.
    - nivertech 3y ago
      What noboody mentioned is that generic tools like AWS AppSync, PostGraphile, Hasura, etc. are actually anti-pattern for anything public facing, as they expose the data model and copy it as-is in GraphQL. GraphQL server is a special case of the BFF pattern, and the whole purpose here is to decouple FE from the underlying data model on the BE, and let both to iterate faster without blocking each other.

mannyv 3y ago

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). 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.

DGCA 3y ago
1. async/await is a thing. 2. The GraphQL spec tells you how errors should be handled.

JackMorgan 3y ago

My main takeaway: GraphQL moderately improves developer enjoyment (DevEx) by majorly increasing the cost of making production ready APIs. 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. 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.

unusualmonkey 3y ago
Depends how you use it. We use Hasura, and find this massively decreases the cost of making production ready API's vs traditional REST development.