Ask HN: What is your present sentiment on GraphQL?
A few years ago GraphQL was looked at by many as a Next Big Thing. I'm looking for a comparison from developers who have now implemented REST APIs as well as GraphQL APIs in production. What is your preference now and why?
16 コメント
Comparing with REST(ful/ish) APIs...
From the consumer side I really enjoy using it. Queries can avoid lots of network chatter and mutations embrace procedural thinking (REST has answers CRUD, but not everything a server needs to do is resource based).
However, as a server dev I really don't like it. It puts much more power into the consumer's hands without providing good visibility into the database queries it's making behind the scenes and how heavy those might be.
As I see it, it trades client side complexity for some loss of control over database queries. I often see it sold as the former without mentioning the latter.
From the consumer side I really enjoy using it. Queries can avoid lots of network chatter and mutations embrace procedural thinking (REST has answers CRUD, but not everything a server needs to do is resource based).
However, as a server dev I really don't like it. It puts much more power into the consumer's hands without providing good visibility into the database queries it's making behind the scenes and how heavy those might be.
As I see it, it trades client side complexity for some loss of control over database queries. I often see it sold as the former without mentioning the latter.
Mostly uninteresting. I have made use of GraphQL and haven't seen any practical benefits. APIs tend to be tailored to a specific use case, so the flexibility it offers tends not to get used.
I don't particularly like the error handling. You can get 200 OK responses with errors in them, and I have seen that not handled in reviews two times.
I don't particularly like the error handling. You can get 200 OK responses with errors in them, and I have seen that not handled in reviews two times.
I love it. It provides a set of strongly typed, canonical resources, built-in documentation via schema reflection, granular authorization (which is a huge comfort in large systems!), and a bunch of other stuff. For marrying to a front end, the strong typing implied by the interface (and ability to generate Typescript types) are invaluable; a change in my backend server code that breaks front-end code is immediately caught and surfaced by my compiler.
REST is still great, and it's hard to beat for simplicity, but I also don't consider it to be XOR with GQL. In systems that I already have GQL set up for and for which REST is appropriate, I like to actually build REST APIs as convenience wrappers on top of my GQL underpinnings - rather than a controller action being a set of authorizations, record loads, and transformations to JSON, I just execute a GQL query (in server code) against my schema and consume the result to transform it to the desired output. In practice, this is often what REST APIs are doing ad hoc, but being able to leverage all the guarantees provided by the GQL schema results in very simple, straightforward, flexible implementations.
GQL represents a large shift in how you think about the structuring of an application's API, but done well I consider it flatly superior for systems beyond the trivial because of the reduction in maintenance friction.
REST is still great, and it's hard to beat for simplicity, but I also don't consider it to be XOR with GQL. In systems that I already have GQL set up for and for which REST is appropriate, I like to actually build REST APIs as convenience wrappers on top of my GQL underpinnings - rather than a controller action being a set of authorizations, record loads, and transformations to JSON, I just execute a GQL query (in server code) against my schema and consume the result to transform it to the desired output. In practice, this is often what REST APIs are doing ad hoc, but being able to leverage all the guarantees provided by the GQL schema results in very simple, straightforward, flexible implementations.
GQL represents a large shift in how you think about the structuring of an application's API, but done well I consider it flatly superior for systems beyond the trivial because of the reduction in maintenance friction.
I'd say to use the right tool for the job.
But as a general opinion, I admire the theoretical elegance of GraphQL (only return the exact data needed), but using GraphQL is probably more trouble than it's worth for most projects.
But as a general opinion, I admire the theoretical elegance of GraphQL (only return the exact data needed), but using GraphQL is probably more trouble than it's worth for most projects.
Exactly my thoughts. I like the idea of "one endpoint to serve multiple queries + the query language". I hate the implementation though: one needs the Apollo (or something similar), plus some sort of library in the client side (unless you want to work with graphql queries wrapped in quotes).
I would suggest that GraphQL queries wrapped in quotes aren't bad. I personally don't see the point of using GraphQL client libraries at all.
If you interpolate parameters into your query, then there are yucky quoting issues, but GraphQL allows clients to pass both a query and accompanying variables for that very reason, and users are encouraged to use variables.
If you interpolate parameters into your query, then there are yucky quoting issues, but GraphQL allows clients to pass both a query and accompanying variables for that very reason, and users are encouraged to use variables.
I've used GraphQL professionally and felt it was great... if it matches your use case. Basically, if your data comprises various different types of entities which relate to each other, and clients are likely to want to pull back data on related entities ("give me these Xs and all the Ys which relate to them"), then GraphQL might make sense.
If there is any significant latency in accessing your backing data store, as is usually the case with a SQL database, then care is needed when implementing your GraphQL server. Naive implementations will have the N+1 problem (or the "N²+N+1" problem, etc) and will be slow.
I haven't found a GraphQL server library which I like, so I implemented my own. (I found an MIT-licensed query parser, which saved some work.)
It is designed to make no more than one SQL query for each branch node in the GraphQL query AST (assuming that each type of entity is stored in a single table). Running in production for a while now, works great, fast, was fun to write.
If there is any significant latency in accessing your backing data store, as is usually the case with a SQL database, then care is needed when implementing your GraphQL server. Naive implementations will have the N+1 problem (or the "N²+N+1" problem, etc) and will be slow.
I haven't found a GraphQL server library which I like, so I implemented my own. (I found an MIT-licensed query parser, which saved some work.)
It is designed to make no more than one SQL query for each branch node in the GraphQL query AST (assuming that each type of entity is stored in a single table). Running in production for a while now, works great, fast, was fun to write.
I think it exposes a better more consistent contract between the frontend and backend, but I might not use it if my product were an api - it's harder for users who are used to traditional rest apis to consume.
I like how as a backend engineer you can just publish all the data that makes sense in the graphql schema and the frontend folks can just grab whatever they want in a single request to populate whatever view they're working on - easy to explore with graphiql, and you can introspect the schema to generate types for typescript...
I like how as a backend engineer you can just publish all the data that makes sense in the graphql schema and the frontend folks can just grab whatever they want in a single request to populate whatever view they're working on - easy to explore with graphiql, and you can introspect the schema to generate types for typescript...
I dont like it at all. I think it just tries to solve something that's not a big deal.
I prefer GraphQL because making beautiful and convenient large REST APIs is very difficult, almost impossible, while it's trivial in GraphQL.
I feel like REST is shoehorned on top of HTTP, which was never designed for that. It has some advantages such as accessing features from the HTTP toolchain, like easy caching and many developer tools, but I think GraphQL is more adapted as an API layer unless you want a tiny CRUD API for one resource.
Also I think GraphQL schemas are easier to work with than Swagger/OpenAPI specifications.
You have many other alternatives too, such as SOAP, CORBA, or gRPC, but I would prefer GraphQL unless an alternative is a lot more adapted to my problem. It's still JSON and HTTP, which makes it easy to work with, and it's powerful enough.
I feel like REST is shoehorned on top of HTTP, which was never designed for that. It has some advantages such as accessing features from the HTTP toolchain, like easy caching and many developer tools, but I think GraphQL is more adapted as an API layer unless you want a tiny CRUD API for one resource.
Also I think GraphQL schemas are easier to work with than Swagger/OpenAPI specifications.
You have many other alternatives too, such as SOAP, CORBA, or gRPC, but I would prefer GraphQL unless an alternative is a lot more adapted to my problem. It's still JSON and HTTP, which makes it easy to work with, and it's powerful enough.
I think that it has some really nice advantages, but it has some glaring issues that make its use case somewhat limited.
When you are defining some component and you can define exactly the query that the component will need in the same place, that is great.
However, doing normal things like file uploads introduce clunky extra steps like sending a mutation to get back a url that you then make the upload request to. Clunky.
Further, in the past my team has experimented with trying to do multi-model transactions with I think Apollo graph ql library, and it was not readily possible. That was back in 2020, maybe things have improved since then?
When you are defining some component and you can define exactly the query that the component will need in the same place, that is great.
However, doing normal things like file uploads introduce clunky extra steps like sending a mutation to get back a url that you then make the upload request to. Clunky.
Further, in the past my team has experimented with trying to do multi-model transactions with I think Apollo graph ql library, and it was not readily possible. That was back in 2020, maybe things have improved since then?
[deleted]
GQL is great, if only because it stops endless bikeshedding about "what is RESTful". It's not going to be right in every use-case and I find it useful to have GQL and normal API endpoints on the same API so I can use the right tool for the job.
From a client perspective it's night and day, server implementation is a little more tricky but the C# libraries seem to avoid a lot of the pain other back-end answers seem to be encountering, not sure why that should be.
From a client perspective it's night and day, server implementation is a little more tricky but the C# libraries seem to avoid a lot of the pain other back-end answers seem to be encountering, not sure why that should be.
I'm working on the backend and the front end that consumes the data.
From the front end perspective it's really great. I like how flexible the querying is and how concise it makes the comm code.
From the backend perspective, I'm not sure yet how to properly implement authentication; I haven't yet touched mutability. It seems more complicated than REST, but I wonder if it's because I'm very new with this.
Ultimately I'm sure there are gonna be rough edges, but as a consumer it's a very pleasant experience.
From the front end perspective it's really great. I like how flexible the querying is and how concise it makes the comm code.
From the backend perspective, I'm not sure yet how to properly implement authentication; I haven't yet touched mutability. It seems more complicated than REST, but I wonder if it's because I'm very new with this.
Ultimately I'm sure there are gonna be rough edges, but as a consumer it's a very pleasant experience.
I much prefer working with the GraphQL spec than with OpenAPI spec.
I think it's a result of OpenAPI being a very large spec that supports constructs that most languages don't deal with properly (like a field being able to be a number or an object), but a lot of OpenAPI code generators just don't work reliably.
GraphQL isn't perfect in this regard - a lot of languages don't really support union types - but I've found GraphQL client code generators to be more reliable in practice.
I think it's a result of OpenAPI being a very large spec that supports constructs that most languages don't deal with properly (like a field being able to be a number or an object), but a lot of OpenAPI code generators just don't work reliably.
GraphQL isn't perfect in this regard - a lot of languages don't really support union types - but I've found GraphQL client code generators to be more reliable in practice.
It's good for certain use cases that don't have too much data or don't care too much about performance when doing joins.