If you are using REST, I have something to tell you. Its time to stop using it. Creating REST APIs which return JSON or XML has many cons. There is...
For further actions, you may consider blocking this person and/or reporting abuse
Time to stop using REST...
Well, that's some loud words, let's just forget about fancy rules that rest requires and think of it as GET/POST/PUT/DELETE requests for simplicity.
You can send these requests from anywhere (web app, server, mobile application, cli) without any special tools (graphql clients). Sure you can send the graphql request without a client also but it will create a real mess in your code, so in 99% you are stuck with graphql client which in case of web applications brings some weight to the bundle.
In terms of server setup – graphql is pretty demanding – you need to setup at least some boilerplate, create schema and manage resolvers. This does not worth your time if you build a small application and need just several simple crud endpoints.
Also do not forget that you need to be careful with how your graphql data is resolved with recursive elements, e.g.
{ author { comments { author { comments { ... } } } } }.Exactly. And I'm really really worried about exposing data structures, and in the case you allow writing back to database: authorization and authentication. It looks like there are solutions out there but none seem ideal at the moment. The overhead of graphql server should not be overlooked as well. It's one more piece of the puzzle you have to handle.
No matter REST, JSON-RPC, or GraphQL, if the data structure (schema) is changed, everything is screwed.
However, with GraphQL you can usually get a type error when you send the query, instead of wondering why the code is accessing a field on
undefined.I would also include to graphql cons:
I'd also add that OpenAPI supports type checking for REST. There are several code generators just like Graphql for multiple languages.
There's another simple alternative to REST. Just implement an API that uses an HTTP POST to send up a JSON request and get back a JSON response, and then design it like a normal RPC API where it's not technically REST because you invent and use VERBS like the whole world used to do before Roy Fielding brainwashed everyone. :)
I already had 20 years of coding experience before Fielding invented REST so he didn't really affect my way of thinking. I always thought the HTTP verbs have absolutely no place in an API, no matter how clever people get at cramming square pegs thru round holes, which is what REST is all about,
In REST everything looks like a noun, because nouns are your only tool, just like if your only tool is a hammer everything starts to look like a nail.
If you are responsible for both backend and frontend, GraphQL just causes unnecessary overhead unfortunately.
With HTTP2, and soon HTTP3, multiple requests are often considered faster than a single request fetching everything.
And if you'd really wanted to, you could create non-cruddy rest endpoints that fetch a mixed bag of data for your tailored needs (that is, you own the backend).
We are currently using json:api which sits on top of the good old REST which gets us most of the described features here like "sparse fieldset" and "includes" and we are very happy with that so far. But there's also a lot of boilerplate on the server side for that.
As many mentioned it's quite wrong assumption. REST has probably been adopted as it fits way better in those use cases than any other model in many client-server communication. Just because Facebook required more and then people found it easier in their use cases doesn't make GraphQL better just different. POST-ing constantly and mutating can be an extreme waste of network traffic and processing power if most clients require quite the same data (extra one-two fields are really not important) which has been frequent in my case - example REST would have no data just GET and all clients use most of the stuff from the DTO. If you build internally stuff and have no intention of exposing API-s how much chance you have of having different requirements per resource? Usually smartphone apps and web use either same data or different resources which is, well resource, so different endpoint. And talking about different architecture using gRPC - we had SOAP didn't go well. Try to pick the right tool for the job and other tools won't look so bad.
Another CON of GraphQL is the inability for optimization beyond DataLoader. As each generation knows only about itself and a limited amount about dependents, the system as a whole cannot use multigenerational joins or optimizations
Public API's do well with GraphQL as the hosts don't know exactly what the callers want from the API. Internal API's are less clear-cut. Often, the caller developer and the host developer are teammates, and the efficiency of a focused REST (or gRPC) call is better
flexibility ∝ efficiency⁻¹
GraphQL Playground is missing a major feature: fill in all the fields of a type.
Altair GraphQL Client has this feature.
altair.sirmuel.design/
I'll check out Altair GraphQL Client. Thanks for the tip!
This is when the server side maintains each version indefinitely. I'm developing the server and I don't want to do that.
I see, GitHub API has HATEOAS. However, if the client code isn't an AI, it still breaks when the schema changes.