I worked on two projects using GraphQL and don't want to do it again. Both times the backend was a mess and the "design" or the lack thereof had all the signs of being written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess. I'm sure GraphQL is the right fit for some problem domains, but most of the problems I deal with are happily solved with the help of a REST API.
After 6 years, I'm over GraphQL
111–120 of 721 posts
Re: After 6 years, I'm over GraphQL
#112Several years ago, I used to respond to conversations where people hated on Facebook by saying that Facebook had given us at least two great gifts — react and graphql. Since then, I've grown to realize that these might in fact be its two great curses.
Re: After 6 years, I'm over GraphQL
#113Unfortunately it has become fashionable in SaaS products to only offer GraphQL endpoints, thus whatever we think about it, GraphQL it is.
I don't interact with that many SaaS products, but I've never seen that
If you want to be pedantic, some do offer REST or GROQ as well, which aren't much of an alternative anyway.
Re: After 6 years, I'm over GraphQL
#114Earlier quoted context omitted.
The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…
I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?
I'm not that much into GraphQL but I vaguely remember libraries that provide some kind of atteibutes you apply to entities/loaders and then pre-execution an estimated cost is calculated (and aborted if over a specified threshold).
Re: After 6 years, I'm over GraphQL
#115Several years ago, I used to respond to conversations where people hated on Facebook by saying that Facebook had given us at least two great gifts — react and graphql. Since then, I've grown to realize that these might in fact be its two great curses.
What do you dislike about React?
Re: After 6 years, I'm over GraphQL
#116Earlier quoted context omitted.
GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…
Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…
> It is far better for the Backend to provide Frontend a contract
It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3).
> This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates.
It is true it can cause these kind of problems, but they take far, far, far less time than mundane contract agreement conversations. Although having catastrophic failures is usually pretty dire when they do happen, but there are a lot of ways of mitigating as well like good monitoring and staggered deployments.
It is a tradeoff to be sure, there is no silver bullet.
Re: After 6 years, I'm over GraphQL
#117If only developers/managers had their own sense of using the proper tools for the job instead of just swallowing everything the Big Tech shoves down their throat...
But when you see those job ads with all these "great new technologies" it's hard not to fall into the trap.
Re: After 6 years, I'm over GraphQL
#118At work we also stopped using Graphql and we only have a few endpoints left to migrate in our internal dashboard.
Nobody that has worked on this project has liked the dx.
Re: After 6 years, I'm over GraphQL
#119Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me.
One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already 'vetted'", where you can look at things like complexity, ACL behavior, etc ahead of time. Since clients (in my experience) aren't usually modifying GQL queries at runtime, this is a pretty good tradeoff.
All that said, I find Buf Connect to be the best set of tradeoffs for most projects: strongly typed servers and clients, strong ecosystem support around protobuf (e.g. to generate an OpenAPI spec), a standard HTTP/JSON interface for easy curl et al compatibility, etc.
OpenAPI as the source of truth is annoying because it's too flexible, and it's rarely possible to generate type-safe servers + clients from an OpenAPI spec without running into one edge case or another.
Re: After 6 years, I'm over GraphQL
#120Earlier quoted context omitted.
I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?
I'm not that much into GraphQL but I vaguely remember libraries that provide some kind of atteibutes you apply to entities/loaders and then pre-execution an estimated cost is calculated (and aborted if over a specified threshold).
That's sort of my expectation too -- it would be nuts to provide a user facing system without bounds of some sort.