GraphQL is a Trap?.
This twitter thread blew up on twitter yesterday and I thought I’d go over some of the author’s points in a longer format so we can clear…
Read in full here:
https://xuorig.medium.com/graphql-is-a-trap-e83ca380aa8f
This thread was posted by one of our members via one of our news source trackers.
I haven’t really learned and used GraphQL, but maybe it is useful only in some scenarios? Maybe REST should still be your default?
This seems like a good article, I’ll add in too:
Claim 1: GraphQL Makes Your Public API Equal To A Generic Graph Database
Uhh, no? It’s an RPC model that happens to be able to refine what can be returned so you don’t get superfluous data eating network and processing. The RPC model is actually quite nice, gets and mutations are well defined, great docs, etc… It’s far more of a modern better SOAP than it is a ‘generic database interface’.
There are even standards for handling versioning of the API’s as well (as in SOAP too).
A generic GraphQL API actually goes counter to what most would consider best practice. In fact, the GraphQL Spec has consistently rejected proposals for generic / database-like features (like filtering, ordering, etc).
YES! Because GraphQL is an RPC model, not a database model.
Claim 2: The amount of maintenance work is sky high
Not remotely, like holy wow is it easier to manage than a SOAP system, and the abstractions the libraries for it do allow for easily changing the backend without changing the API, it’s been blissful to use in comparison to any other RPC model I’ve dealt with yet, especially in maintenance!
Claim 3: Locking the query capabilities down means you’re just doing normal APIs but not locking it down means infinite performance work
Uhhhh, again wut? GraphQL is utterly amazing at reducing the amount of work, backend processing, and network traffic needed!
A GraphQL API generally can’t be as optimized as other APIs because of the flexibility it offers.
Now of the article writer I’d disagree with this, you can not only optimize as well as before but you can optimize better because you can remove unwanted information from the processing and network load entirely. At the absolute worst you just expose an identical API to, say, SOAP with whatever process processing you want. It is an RPC framework after all.
[Tweet 5] In a SQL db, typical GraphQL needs nested queries-in-queries-in-queries and unbounded joins and those are well-known to be reliability, performance, code-malleability, and comprehension problems. And these problems are only an expression of the issues of all generic graph APIs
Uhhhh, wuuuut? GraphQL is RPC, it’s not tied to SQL at all, it doesn’t have anything to do with SQL at all, easily half my GraphQL calls don’t or barely touch the database at all. And the quality of your SQL has nothing to do with the RPC framework but all about your code (of which even my most complex queries with my largest RPC calls don’t do nested queries-in-queries-in-queries and unbounded joins at all, like learn SQL and do things right, what on earth… >.>
Oh, and GraphQL is not a generic Graph API
+1 It’s a modern SOAP, a modern RPC framework, a really really really nice RPC framework, it puts gRPC to utter shame in just how much better it is as an example. It is not a Graph API, it has nothing to do with graphs at all other than it originally came out of Facebooks Graph handling division (which just needed a good RPC layer between their servers and mobile clients).
A GraphQL API, especially a public one, can’t be as predictable as server-driven use cases that are known ahead of time and optimized individually.
Except it can, you can treat it exactly like a basic SOAP/gRPC layer with all the optimizations you can think of (of course with the built in thing of not sending parts of the data the client doesn’t want over the network to reduce load, which you can’t do as easily with SOAP or gRPC without doing it manually).
- design your APIs according to your database schema.
- Always use async/batch data loading (like dataloader) when you can, don’t create monster SQL queries based on look-aheads or gql-to-sql tools (as a general rule of thumb)
- Avoid generic features if you can’t support them in an efficient way. Add functionality only when needed and when performance is adequate.
+1
Eh, the rest of this article still seems good, lol.
But yeah, GraphQL is nice, it’s a very good RPC model, and it is far superior to REST, far far superior.
It’s generally useful when you need to send data between things with an API that can change as demands need, or at the very least as a very basic RPC framework. It is better than REST in every way, there’s no point using REST except just for backwards compatibility, and you can put a REST API on top of a GQL API by just specifying defaults and such.
Graphql is actually a very flexible tool for FE to create something simple for internal or personal project, considering the access right design is not very complicated.
As a client facing application, it is hard to duel with the scales.
