|
|
|
|
|
|
by jelan
981 days ago
|
|
|
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 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 |
|
|
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?