Translations: Russian
Edit this chart
Watching recent trends in client-server paradigms, from Apollo GraphQL to React Server Components to Ra...
For further actions, you may consider blocking this person and/or reporting abuse
Yes a bit click baity ;).
I can distill it down to “backend devs love rest and front end devs love GQL”. The reason is simple: you have to pay the complexity cost somewhere. From multiple experiences I can point to GQL pushing complexity to the backend and rest pushing complexity to the front end.
For me, the transport mechanism matters less these days. I do prefer GQL because it forces you to think and model your data as an infinitely extendable graph. Last project I used rest on we went through the hoops of trying to find a way to fetch related models, and select specific fields…
In the end, however you can build and maintain something of value wins regardless of the tech or framework.
And nice article review of the options!
I’m not sure if gql results in bigger complexity on the backend. If you consider schema first approach. When designing an API it forces consistent schema on the backend and it's something not only fronted dev will appreciate. An even more interesting approach would be not to write your resolvers at all and use gql schema to construct a graph DB - take a look at Dgraph. Doesn't it cut the complexity of managing separate DB, rest API, and keeping documentation up to date?
I'm afraid with Dgraph I might run things that need to be changed later. Not sure that's a valid fear. There are similar solutions, like how with Hasura you can generate the schema based on your PostgreSQL schemas.
Did you considered JSON:API specification? It supports both features within REST architecture.
In my experience many issues with REST are caused by using an ad-hoc architecture, which can't support the features needed.
Is it true that FE devs love GQL? To us it's just another string to send to the BE, it could've been a SQL string for all I care.
it shifts a lot of work from FE to BE, of course FE dev love it 🙃
Well written! This sorta also serves up as a guide to choose your client-server model.
Personally I have been a fan of GraphQL because of type safety, auto caching and codegen. As a middle-ground I'd recommend using the Open API spec(swagger.io/specification/) for REST and a smart GQLish client like React Query(react-query.tanstack.com) along with Orval(orval.dev) for client codegen.
Cheers!
thank you for the personal recs!
My own take on REST and GraphQL with analogues from the SQL database world:
REST <---> direct client SELECT query to database
GraphQL <--> a call to stored procedure on database
There are no free lunches. REST is more flexible and simpler but you have to do more work on the client side to merge together data queried from diverse sources.
GraphQL basically delegate the merging work to the server side but some handlers has to do the job. And you need some query/merging schema know-how to do the job.
Similar to JSONAPI from @thxdr's comment, OpenAPI (formerly Swagger) is another superset rest spec that offers a unique perspective on REST API usage.
Thanks for this article Shawn!
I wish people would stop saying "REST" when they mean "HTTP server that maps HTTP verbs to CRUD operations and uses JSON for input/output".
You can't "kill REST".
It is a set of architectural elements and constraints that apply to a distributed cross-organizational anarchic client-server messaging system like the web. It is how you design something like HTTP.
REST does not automatically mean CRUD verbs, not does it mean JSON, nor does it even necessarily mean using HTTP as your messaging mechanism.
You can have a REST-adhering system that runs on HTTP, MQTT, or smoke signals. You can describe interactions in JSON, GraphQL, or protobuf.
Looking at it through that lens, it really matters more whether you're able to categorize a client's requests as cacheable, destructive, and/or idempotent and send back a response that represents an atomic state with hyperlinks to other valid states, so that the whole system can be scaled by infrastructure that's oblivious to the application-specific meaning of a particular message.
Many so-called "REST APIs" do not meet that criteria. Not even close. They implement a thin veneer on top of DB operations, maybe with some validation if you're lucky. It's then up to the client to have intimate understanding of valid state transitions and the characteristics of each specific request.
Moreover.... Most systems that claim to be "RESTful" shouldn't even strive to follow REST! The architectural constraints just don't make sense for (or are fundamentally incompatible with) the problem they're trying to solve.
I think where we screwed up with SPAs, as an industry, is that we took inspiration from the document-based web instead of from realtime video games.
Imagine trying to represent Counterstrike as a series of hyperlinks. I mean, you certainly could -- Twitch Plays Pokemon is something akin to that. But it's not a practical implementation for that system.
The real problem here is that even when devs understand REST deeper than "JSON CRUD over HTTP", they get the order of operations wrong. They think "Well, HTTP is the most readily-available mechanism I have in this component... and REST seems like a natural fit for HTTP..." instead of "Is REST the right set of constraints for this component? If not, can I find a mechanism other than HTTP, that makes more sense for the right set of constraints?"
Have you heard about Database stored procedures?
If not, read on below:
Traditionally, clients would be sending a one or more SQL to database(backend) to query the data they need. A number of times, they just fetch data from server and merge/aggregate the data on the client side. In short the smart logic lies in the clients know what they want and how they want it.
This is analogous to calling REST API backends.
However,...
Client queries are expensive and slow and tedious to do over data that spans several tables with complex joins...and you need to know SQL really well.
This is where database stored procedures comes in.
You predefined a "function" on the database backend that takes in several parameters. Every programmers knows what a function is.
This database "function" is called Stored Procedures. Look it up.
So its like a GraphQL endpoint.
So you just send query parameters to the backend database instead of sending raw SQL queries. You don't even need to know SQL!
The data you need from several queries are run and merged by the database stored procedure automatically. Isn't that neat?
I see GraphQL as a reinvention of backend database stored procedure ala web style.
I believe what you are referring to as "Smart Server" is what we used to call the "Postback" model, because you post a form back to the server which returns html back to the client and forces a refresh of the page.
I feel like the post didn't do much to directly compare REST and GraphQL. What most people do with REST today isn't really RESTful. There is no HATEOAS usually. So, all the benefits we should get from REST we don't. Honestly, it is something that GraphQL managed to pull off in a different way.
Nice write up Shawn!
REST is fine, but the amount of work you can save with GQL and codegen is massive.
You can also do codegen with REST, if it's open api specced. Although to be fair in general I had more problems with open api codegen than with GraphQL codegen.
ran across this: github.com/dunglas/vulcain
Just reminds me of Progressive Web Apps (PWA) for Smart clients. But yes it's a different form abstraction with it own pros and cons.