21–30 of 41 posts
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.
"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.
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.
"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.
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
You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who use your API to write frontend clients.
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.
"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.
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.
Earlier quoted context omitted.
"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.
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 night…
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.
Significant engineering time will need to be spent ironing out important things that just work with REST (like caching).
The best analogy I have for what working with GraphQL on the backend is like is the “If you give a mouse a cookie” story [1].
You try to set up an API but end up being asked to implement three different caching layers, using the data loader pattern to batch requests to the DB to improve performance, discovering that custom error handling code is needed to get non 200 status codes back from your API, using persisted queries now that your frontend is asking for a lot of data in the body of the request which is taking up too much bandwidth, etc…
The code as you can imagine after doing all this is very hard to follow, even without doing any of the optimizations I listed above there are things like reference resolvers that make tracking down bugs or just finding where the data is being collected from a nightmare.
[1]: https://en.m.wikipedia.org/wiki/If_You_Give_a_Mouse_a_Cookie
GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes. Significant engineering time will need to be spent ironing out important things that just work with REST (like ca…
I understand why GraphQL might make a lot of sense at a very large scale, but how does it add anything noticeably positive over REST to a trivial project to make up for the extra work?
GraphQL basically a layer that hides data federation from the client.
Would this benefit encourage you to use GraphQL as your backend/data api layer?
Really, it's just more awkward than writing a straight-ahead REST implementation.
Also the error-handling semantics gets pushed to the backend, and the frontend team (who generally doesn't like handling errors) doesn't really know what to do with errors in general...so the UI design team needs to add that sort of error handling to the UI which makes everyone confused because usually there's nothing you can do about errors on the client side.
The error handling issue can be seen with this simple example: you federate 10 API calls, and 9 of them work fine. Do you return partial data? How do you indicate to the front end that there's partial data? What if the data in the 10th call is the one they need in the UI?
This implies that you need yet another state indicator that says "part of the data was returned" (if the destination was a field)...which is different than "that field was empty." And that's at a minimum.
The comment:
GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema:
type Error {
message: String!
}
type Query {
hello(name: String!): QueryHelloResult
}
union QueryHelloResult = Error | QueryHelloSuccess
type QueryHelloSuccess {
data: String!
}
query {
hello(name: "World") {
__typename
... on Error {
message
}
... on QueryHelloSuccess {
data
}
}
}
I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way.
[0] https://www.youtube.com/watch?v=yab6i9lrEv0