I'm resistant to GraphQL, although I take the caveat that I was also initially resistant to JSX and CSS-in-JS and my thinking has since evolved.<p>My two main annoyances are a) GraphQL could be thought of as a custom media type that almost "slots in" to the REST model by defining a request content-type and a response content-type with almost entirely optional fields, and b) the incessant idea that REST has to replicate the n+1 query problem.<p>For a) "it's strongly typed" has never struck me as much of an argument. It's appealing if you're already lacking a strong definition of your data model, but GraphQL doesn't inherently fix that, it just forces you to confront something you could fix within your existing architecture anyway.<p>For b), it seems that people tend to map something like /users to `SELECT * FROM users`, and 12 months later, complain that it's retuning too much data, and they have to make N queries to /groups/memberOf.<p>Am I alone in thinking the obvious solutions are to i) add a comma-separated, dot-notation `?fields=` param to reduce unnecessary data transfer, ii) add an endpoint/content-type switch for `usersWithGroups` and iii) realise this is a problem with your data model, not your API architecture?<p>As an additional c), my other concern is GraphQL touts "one query language for all your data", but tends to skip over the N+1 problem when _implementing_ the queries to disparate data sources. If your existing queries are bolted into `foreach (input) { do query }` then GraphQl isn't going to give you any speed up, it's just going to give you slightly more simplicity to an already-slow backend.<p>Granted, I work with "legacy" (i.e. old but functional) code, and I secretly like the idea that adopting GraphQL would force us to fix our query layer, but why can't we fix it within the REST model?<p>(I happen to be about to sleep, but I am genuinely interested in waking up to see what HN thinks)
I'm becoming somewhat suspicious of <i>both</i> REST and GraphQL for APIs. Not in the sense of thinking that they're bad or antipatterns or anything so hyperbolic as that, but in that they make some fundamental assumptions about how APIs are going to work that I don't think we should ever just take for granted.<p>On the REST side, it's the assumption that the API is for state <i>transfers</i>. Transfer is a heavy word there. You're not just assuming that the service is stateful, and you're not just assuming that clients can ask for state changes. You're assuming that the dominant model for effectuating those state changes is that the client determines what the new state should look like, and transfers a representation of that state to the server.<p>And then, on the GraphQL side, you're assuming that the service is basically just a big database. Perhaps one with lots and lots and lots of behavior that, from a high level, looks a lot like triggers. But still, a database.<p>Both these assumptions may work well for a whole lot of applications. If CRUD's your ticket, then both can serve you well. But choosing either might force you to make some compromises if you were instead hoping to do come up with, for example, a more domain-driven design.
One consideration I rarely see mentioned when discussing REST vs. TechDuJour is:<p><pre><code> who are your users?
</code></pre>
If you develop an API for your front-end team, use the fastest, most efficient protocol. Use something that you can change quickly. Optimize for speed in all regards.<p>If you develop an API for other users and they expect that API to be around for a while and gradually grow, then you need to think about how much pain are you going to subject your users to when your API changes.<p>GraphQL: You will not get your domain model right on the first attempt. So you will need to change your "Graph". Your "Graph" might change substantially. How do you deal with that?<p>REST: Same thing: There are well-known standards how to grow and evolve a true RESTful API. Yet, you may still mess with your users, declare a /v2/ endpoint and discontinue /v1/
I've used GraphQL and Hasura extensively for my project (<a href="https://pagewatch.dev" rel="nofollow">https://pagewatch.dev</a>) and it has been a huge timesaver to get a realtime service up and running. BUT, I'm still using REST for mutations (The POST/PUT part really).
At least for my use case I find that almost every time you are modifying data there is some other component also involved (eg starting a background task), so it might as well be a REST server endpoint. (Also I find the mutations language of GraphQL is really the weakest/hardest to really understand part)
Great article.<p>REST with JSON has always been a category error: JSON is not a hypertext and thus, as the author says, violates the most important and distinct aspect of the REST architecture.<p>I have written quite a bit about this:<p><a href="http://intercoolerjs.org/2016/01/18/rescuing-rest.html" rel="nofollow">http://intercoolerjs.org/2016/01/18/rescuing-rest.html</a><p><a href="http://intercoolerjs.org/2016/03/15/hypertext-hypotext.html" rel="nofollow">http://intercoolerjs.org/2016/03/15/hypertext-hypotext.html</a><p><a href="https://threadreaderapp.com/thread/1276556432385531906.html" rel="nofollow">https://threadreaderapp.com/thread/1276556432385531906.html</a>
My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD. To top it off, because people want "beautiful" REST APIs everyone has a playground to do these kinds of things differently. And boy are they done very differently from company to company. And that leads to massive opinionated people. Finally, REST is tied to HTTP too tightly. It can't be independent of it, ever. I know a lot of people believe that's a good thing, in that there are metrics, logs, and a variety of data that assists architecturally. But it has only reached that status because we're sitting at 15 years of REST toolchains.<p>I'm not saying GraphQL is the long term answer, but personally I'd rather be in a project using GraphQL (and hopefully not backed by REST at all)
We should resist attempts to turn technology choices into religious devotions. Here's an example of a project that brings some of the most significant benefits of GraphQL to an established, mature framework for building REST APIs:<p><a href="https://github.com/yezyilomo/django-restql" rel="nofollow">https://github.com/yezyilomo/django-restql</a><p>It's tempting to think your new paradigm/framework/whatever is so groundbreaking, so purely beneficial, that it warrants asking people to demolish everything and start over. Those kinds of breakthroughs have happened and will continue to happen, but the signal/noise ratio, especially in the world of Web Development, is incredibly low.
I have been working on an idea to leverage SQL + REST APIs instead of GraphQL to solve the similar problems, and I would love to get some feedback on it.<p>GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.<p>My solution (<a href="https://github.com/hashedin/squealy" rel="nofollow">https://github.com/hashedin/squealy</a>) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.<p>Handling many-to-many relation, or many one-to-many relations is done in-memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.<p>Here is an example that builds various StackOverflow APIs using just a YAML+SQL based DSL - <a href="https://github.com/hashedin/squealy/blob/master/squealy-app/squealy-home/dba.se.com.yml" rel="nofollow">https://github.com/hashedin/squealy/blob/master/squealy-app/...</a><p>Squealy is still work in progress, so don't use it in production. But I would love to get some feedback!
Im right now building my backend on GraphQL and TypeScript.<p>Great DX.<p>GraphQL Modules + TypeGraphQL, Apollo Server, TypeORM (pg for prod and sqlite3 for dev/test)<p>Works pretty nicely auto-generating both graphql fields/querys/mutations/schema and entities/models from database from a single source of turth. I made a template from type-graphql's graphql-modules example to work as a separate codebase, if someone is interested I could switch it from private to public and share the link here
Thanks for this article! I'm currently writing my Bachelor thesis, designing a new API for an existing architecture is part of my project. I've been considering going with GraphQL instead of just overhauling the current REST API and this is a pretty good starting point.
Use Graphql if you have multiple teams that don't own their back-end, and you have multiple clients (Web, Mobile, SPA, Desktop...) consuming your data, and your front-end always has to consume multiple APIs and resources, and you don't count every milliseconds.
I love GraphQL because it is a standard people can agree on, if nothing else.<p>It is a very long list of decisions your team does not have to make. How to handle mutations and queries, how to represent your domain objects, all of this can be decided through referencing the spec and best practice.<p>Throw in the fact that it REQUIRES you to define a strict schema that has validation, and I am sold. The tooling is great, you get great documentation out of the box, the architecture is good enough, it is totally win-win in my book.<p>I feel like with REST you have to reinvent the wheel over and over again, and the lack of standards leaves the burden on the team, who may not be senior level engineers.. ( If I have to write another validation library I am going to flip out. )
Having written <a href="https://glennengstrand.info/software/architecture/microservice/graphql" rel="nofollow">https://glennengstrand.info/software/architecture/microservi...</a> which is a blog entitled "GraphQL vs REST" I must admit that I was initially on guard with this blog. In then end, they did compare and contrast GraphQL with REST. I don't wish to go over this article point-by-point but their main arguments against REST seems to me to be this...<p>1. too many endpoints<p>2. too much data retrieval<p>3. too much coupling between clients and servers<p>The blog does not discuss when to choose REST over GraphQL since that would be in conflict of interest with those who hold Hasura equity.<p>Technically, GraphQL does decrease the amount of endpoints to one but at the cost of increasing client-side complexity because now client devs have to write what is essentially a query. To do so, they have to understand the backend schema. I would argue that this is not the greatest in terms of clear separation of concerns. I would also argue that this means that there would be even more coupling between client and server.<p>I won't cover the n+1 point since others here have already done so.
GraphQL with Apollo on the front-end provides very nice front-end global state and cache management, but at the cost of increased complexity. For example, fetching data updates the global state so that any page accessing that data is updated automatically.<p>Are there any lighter weight RESTful JS client state/cache management solutions out there people can recommend?
I think REST works if you need to fetch data but when you want to query data, I prefer a well defined language instead of hacking my http headers into a query language that I need to define, implement and maintain.
Check out <a href="https://open-rpc.org/" rel="nofollow">https://open-rpc.org/</a> if you haven't seen it. Brings GraphQL-like tooling to JSON-RPC.
The primary difference here is that REST is an actual architectural style with constraints.<p>GraphQL isn't. It's a data query mechanism expressed in JSON.
GraphQL makes sense if it is consumed by UI(frontend). But REST still the best for server side consumption. That is one application interacting with another application in the backend. I have seen people interacting with GraphQL for server side as well - but it is over-engineering and increases complexity. IMHO GraphQL is for humans, REST is for machines.