Indeed, not a great advertisement for the organizing companies. If you're selling a CMS (yes, even if headless), a fast site should be bread and butter...
A lot of these can be addressed using a combination of Apollo GraphQL and dataloaders. This is especially true if you move most of the hard work to the backend and use optimistic updating on the front-end to improve the user experience.
GraphQL is an open standard. If you don't like Apollo which, by the way, is open source; you can choose other libraries. To an extent all technology choices produce some level of lock-in, including REST, otherwise you end up rolling your own operating system and transport layer.
Dont think it's absurd... This is just an objection in sales terms. First impression is very hard to change. This is why I asked I wish someone address it more.
I just am baffled how someone can think there is a lot of "vendor lock in" with GraphQL. I am a huge fan of GraphQL, I have used it on large, production systems for years, and I have never even paid any money to any GraphQL tool vendors. Basically all of the good tools are completely free and open source.
The spec is open and not that hard to implement should it become necessary.
I'd say that the vendor lock-in is lot lower than with your typical open-source large dependency like React or Spring, and people are generally happy to accept that.
Graphql isn't that complex, not more complex than the widely accepted SQL schema + query.
Tooling is top-notch (Graphql-codegen, Apollo, Postman, Graphql playground), and is quite easy to use. Junior devs become up-to-speed with GraphQL a lot faster in my experience, because there is a lot more homogeneity in GraphQL while everyone implements their own flavor of REST
You're often dealing with multiple data sources, no transaction syntax and weaker tools for EXPLAIN and optimizations. Seems way more complex than SQL.
Advanced "Left Join" query building similar to Crunchbase search https://www.crunchbase.com/search/ ... with lot of deep LEFT JOIN behind. Opted out for Golang with REST after prototyping with GraphQL
This is my experience too. A negotiated schema + Typescript means many fewer bugs due to unexpected data shapes. Also error conditions are much more understandable.
Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.
> Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.
GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
A REST-ful POST is a pretty standard implementation of a graphQL network call yeah - it's subject to the same limitations and error handling as any other request.
The confusion comes in when are talking about what happens at on the graphQL server and the calls it makes.
Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query.
All that was initiated by a single graphQL query (a single POST) from the client. What do you report back to the client if one out of the three server-side REST calls fails? Depending the schema, your initial query is still successful, it's just that one of the fields is empty or NULL (again depending on the schema). So that by any reasonable definition is still a 200. Even if all service calls failed, if your schema allows for fields to be empty or NULL, it can still be considered successful.
All that is to say that graphQL is not a replacement for REST, it's an enhancement that serves as a negotiable schema between client and service, a data orchestration layer that can stitch together multiple data sources into that schema, and as a pretty robust way to think about what to present to the user in error conditions since every field you want in your query, presumably, serves in the UI in some way. It gives you the tools to intelligently handle when those fields are not available.
You can do that with vanilla REST calls of course and roll your own solutions to the problems graphQL solves (or tries to solve).
> Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query.
I can do that in any Django view, REST or otherwise. How is that unique to Graphql? I really can't see what I gain. You define your response in Swagger or you do it in Graphql.
I was explaining why graphQL isn't a 1:1 replacement for REST because of that.
I feel like you are hearing an argument that I am not making. Use whatever tool is best for the job / infrastructure / business needs. If that's Django cool. GraphQL has its place too.
REST is more like a set of guiding principles around building a particular type of "distributed hypermedia system". It is more correct to say that HTTP itself is RESTful than to say that RESTful systems must be built on top of HTTP verbs.
You need to turn on useGETForHashedQueries. I don't know why it's not the default. Combine that with the @cacheControl directive for automatic cache-control headers.
In the implementation of GraphQL I work with I find that I end up making giant string mutations/queries that I can't use any sort of intellisense for - it's just guessing and checking with running the queries. Is there a better way to get more than passing back a really long string?
I use IntelliJ, in our setup it gives complete checking and autocomplete. YMMV
It sounds to me like you could benefit from some kind of codegen [1] to generate native language code out of graphql and checking the queries at compile/build-time instead of runtime.
GraphQL playground [2] might be a lower-investment tool to help you.
On the client, use the gql tag, a GraphQL code generator to generate TypeScript types from the gql tagged queries and the appropriate editor/linter tooling.
Then everything is checked when building or directly in the editor.
because GraphQL APIs generally have much higher quality than REST-like HTTP APIs. Designing a proper RESTful HTTP API is actually much harder than the GraphQL one.
I've found the opposite. Designing a GraphQL API with the extended tail of important features has been an awful lot harder than with REST Apis.
That's not just in terms of idioms (which are useful for abstraction layer sake), but authorization, performance, all the sorts of things that are very known quantities, with extensive framework integration, in REST land. You get a lot farther with the wide ecosystem of tracing and monitoring tools, API gateways, authenticating proxies, all these API integration points and what have you in JSON api land.
In specific language ecosystems with a specific choice of tooling and libraries you can ultimately make good things happen, but it's not nearly as universal. Apollo is an obvious contender. I also like HotChocolate in the dotnet ecosystem.
There are definitely benefits. GraphQL having typed schematization by default is huge, and arguably that's the best feature. That's something you need to be more disciplined about in REST land (e.g. OpenAPI). But there's good tooling to be had on those fronts as well. Arbitrarily-shaped types definitely come with their own set of maintenance challenges versus more static DTOs.
P.S. HotChocolate's EFCore integration [0] is some of the coolest library tech I've seen. Thanks to C#'s builtin data projection functionality (via LINQ), it's able to automatically build a Hasura-style fully baked GraphQL API directly from your database domain model (which you can transform arbitrarily to limit / add additional functionality to via LINQ). It's still not my default choice in a new app, but if I were going to invest in GraphQL it's probably the strongest contender
IMO every technology have some minimal accepted level of code quality. Usually it depends on the community or ecosystem, not the tech per say. I.e. usually the code quality of Matlab code will be lower than of C++.
IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs. Just like some people do not care to learn Javascript properly because of its perceived simplicity, for the same reason they are also don't care to learn REST properly.
How many of HTTP APIs have a corresponding OpenAPI spec?
And if they have, is it actually kept in sync with the code?
Does it have proper type definitions, or everything is of a type "string"?
If you are a Stripe you can design a perfect RESTful HTTP API, but for a smaller shop it's much easier to build a moderately good GraphQL API than a corresponding quality HTTP API.
GraphQL forces you:
1. to learn it, instead of blindly using code generated by your web framework
2. to think about your schema
3. to think about backward and forward compatibility, how you your schema will evolve
3. to apply CQS (Command/Query separation)
4. to think how to properly do pagination
5. to think about security
6. to think about error handling, error retries and idempotency of your mutations
etc.
EDIT: For me personally GraphQL was one of the triggers to start serious research on Software Engineering, Software Correctness and Code Quality.
> IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs
> How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code
Umm what? Is this specific to NodeJS or something? Cause Django and DRF allow one to very easily and very quickly creating high quality REST APIs that are self-documenting and trivial to maintain. Pretty sure rails and go have similar packages and methods to allow for making excellent REST APIs. In fact I've found it a massive pain and a huge performance cost to add GraphQL to such projects. It's far slower than the REST calls
> - GraphQL makes tasks more complex
> because GraphQL APIs generally have much higher quality than REST-like HTTP APIs.
How on earth do you say, with a straight face, that the reason a task becomes more complex is because the API is "higher quality"? Higher quality in my mind coincides with ease of use, which is exactly where GQL falls down big.
graphql seems like the SOAP craze - a concept with horrific complexity and lack of scalability, being marketed hard by firms that profit from complex solutions.
There’s almost no overlap between SOAP and GraphQL (еxcept that you seem to not be familiar with either of them).
Especially odd is the "scalability" remark, given those are protocols, they have no bearing on any aspect of the "scalability" of the implementation that I can think of.
Actually both SOAP and GraphQL are often used as aggregate endpoints for exposing internal APIs, often for the infrastructure of entire companies (see how GraphQL is used at Netflix for example). So they're predominantly used where you NEED scale, and REST fails them, due to the heterogenous nature of their clients (external and internal) vs. the "prebaked" structure of REST as a large-grain resource protocol (Fielding's words, not mine).
And the "companies that profit from complex solutions" is a rather poor theory. GraphQL was designed by Facebook, which doesn't profit from "complex solutions". Quite the opposite, they want APIs that are accessible both to their teams and the world. Same with Netflix. GitHub. Shopify. Airbnb. PayPal.
Where are those evil companies conspiring to profit from complexity?
> There’s almost no overlap between SOAP and GraphQL
oh they're entirely similar - overly complex data transfer schemes. They both also push too much responsibility on to the client. They also have steep learning curves.
It may have started at facebook, but the graphql industry has a life of its own now. I've seen this with many technologies. People start tooling and consulting companies around some technology and start pushing it hard. If it isn't needlessly complex, why does it have its own conference?
Yeah I got that you think they're "overly complex" but they literally have nothing to do with each other.
REST is simple compared to GraphQL if you have no standards at all and just slap everything with ad-hoc CRUD resources at will. That's what you do, don't you?
Ever tried to implement OData or OpenApi or any kind of structured API covering HATEOAS at all? Do you actually define your own content types, with MIME and so on? My guess is no. You're not doing REST. You're doing JSON CRUD RPC.
REST is a quagmire of competing half-completed standards trying to do what GraphQL does in one step and with least amount of "maybe this maybe that" situations.
Notice nobody actually tackling the “performance issues” part of this, because that is the real problem most experience. A standard implementation gives you n+1 in many scenarios (assuming you don’t have GraphQL on top of a single SQL database or something along those lines).
So how do you fix that? Well you’ve got to do query introspection to resolve certain queries in a more optimized way. Which tends to be more complicated than just…doing exactly what you want to do via a REST endpoint.
Now I’m not saying this isn’t worth it. In many cases it probably is assuming the people implementing your GraphQL server are competent engineers that will be able to optimize where it matters and make it scale. IMO it’s just worth recognizing that it does take more skill to implement a GraphQL server well.
GraphQL solves a frontend problem and also makes it possible to address the n+1 problem. REST only makes it possible if you add batch/specialized endpoints which is not very RESTful and is exactly the same optimization than for GraphQL.
Whether the introspection is hard or not depends on the library. A good library provides you with a set of queries sub-paths and then it‘s trivial to pre-fetch those at an outer resolver.
Nested objects are fine, making a custom endpoint to provide what the client just needs is not what you will find in real REST APIs in the real world. So a lot of n+1 type of requests are made and much of the data is discarded.
I wonder why this is even controversial now. APIs have been like that for about 15 years and GraphQL was created to address that and it does it very, very well.
edit: slver has explained my point of view much better than I have here.
- REST is standardized, because look at all the standards for it (OData, OpenAPI etc.).
- REST is easy, because I don't implement any of those standards.
- REST is flexible, because I don't even understand the constraints of REST and violate them at will turning it into RPC calls, thinking that it's about pretty URLs and CRUD verbs.
Honestly, it's pointless to argue with those folks. Let them believe REST is the solution. It's way above their paygrade to understand why GraphQL exists.
This seems so unnecessarily antagonistic. People violate all kinds of "standards" all the time cause they don't know any better and design stuff terribly. You could pretty much make a terribly designed system in a similar way with GraphQL except maybe less accidentally cause it imposes some constraints on the developer to follow what the library gives you. The benefit of GraphQL is the fact that there's very few ways of implementing it
So it's unnecessarily antagonistic, but then you proceed to agree with everything I said.
Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way.
GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it".
The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine).
When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API.
No, GraphQL can't compete with that definition of REST. But also it's not trying to.
My argument is that I know it’s worse, I know in practice it is your 3rd bullet point, but it’s easy for both the lowest common denominator of developer and manager to work with and understand. It’s technologically inferior but has less complications on the human side of things in my experience.
> So how do you fix that? Well you’ve got to do query introspection to resolve certain queries in a more optimized way. Which tends to be more complicated than just…doing exactly what you want to do via a REST endpoint.
You're talking about having a REST endpoint which has a "prebaked" aggregate query. But this is not plausible when you serve hundreds, or even thousands of heterogenous clients. Even big organizations like Netflix quickly gave up "prebaking" thousands of REST endpoints for every usecase they had across the organization and outside it.
And aggregate query resources are an anti-pattern in REST because it denormalizes the resources. You're supposed to have one resource on one URL. Instead of one resource included in hundreds of ad-hoc aggregate collections at other URLs, each of which are cached (and go out of sync) independently. And if you have one resource per URL... this creates the mother of all N+1 problems automatically.
Yeah I don’t mean REST in reality because as we all know, nobody actually fully follows that pattern and 90% of the time it’s really just vaguely REST-ish RPC over HTTP anyways.
It’s still easier imo to deal with that than the equivalent in GraphQL up to the point where you’re dealing with a large number of heterogenous clients as you describe. And that’s a problem a small minority of GraphQL users are facing or will ever face.
Where are your arguments? There are exactly zero and now everyone in the thread has to work to debunk these baseless claims.
There are exactly two almost valid points in here:
The default implementation has some overhead (for query validation). That may cause performance issues.
If you deliver public data where the full response can be cached, then REST makes that slightly easier (GraphQL discourages transport by HTTP GET).
I have worked with both for many years, GraphQL solves many real world problems. However you might only understand that as a full stack or frontend developer. If you only write APIs on the backend it appears pointless of course.
It depends on what you do. I worked on an application that could be cached heavily and got a very large number of requests and as a result the query parsing and validation mattered.
A new dev at my work is pushing for graphql, and I am sceptical. We have way to much complexity at present and it seems like a new less understood tech that is only going to increase complexity rather than reduce it.
Do you have any examples you are willing to share.
GraphQL is a fine-grained resource protocol, and REST is a large-grained resource protocol. You don't want to serve thousands of 50 byte responses in REST just to get what you need when your app opens, this is why GraphQL allows you to specify this in one response by selecting what you want in the query.
Can you implement this over REST? You can pretend you can, but if you put all those parameters in the URL and have countless ways of fetching the same data via infinite resource URLs, you're essentially bastardizing the concept of one URL one resource, or the idea that your entities each has its own URL, rather than inlining them in countless ways through one-off aggregate resources.
TLDR; REST really doesn't do what GraphQL does. And when you try to make REST do what GraphQL does, it ceases to be REST.
There's a fundamental data modelling issue that any relational-based system needs to address somewhere in the stack.
Data is stored in more than one table and that data often needs to be joined together for the frontend. Embedded REST apis have the same fundamental issue. That work is just "hidden" inside some sort of server side function.
----
Imo, GraphQL and REST face the same fundamental performance issues. The difference is GraphQL allows clients to optimize the data they need in the response. I'd you have a GraphQL performance issue, you'll likely have a similar or worse REST issue.
As someone who works on multi tenant systems where accidentally crossing boundaries would result in millions of dollars in fines…yeah I would like to see more examples of this in particular haha
What about caching? I'm not sure I like my frontend libraries trying to solve caching when I could very easily get that incredibly simply for free with REST and browser or endpoint caching. I'm really hard pressed to find proper examples that describe auth, RBAC, UBAC, caching etc with GraphQL
When it first came about it seemed like a band-aid to try and get around poorly designed REST systems so backend engineers wouldn't have to deal with frontend devs asking for data and new endpoints. I dunno if it's matured enough past that. Not saying REST is perfect and lord knows enough companies abuse it but a lot of stuff is pretty solved with simple, well documented solutions online
75 comments
[ 2.4 ms ] story [ 153 ms ] threadBut I don't see any mention of the time and timezone ?
EDIT: if you subscribe, you can add the event to your google calendar and it shows: 17:00 - 21:50 (UTC+2)
- GraphQL performance issues
- GraphQL makes tasks more complex
- GraphQL schemas confuse junior devs, higher entry level
- REST cache easier
- REST if you understand what you are doing ... can do the same
- REST is better for error handling and tooling
https://www.apollographql.com/docs/apollo-server/data/data-s...
I'd say that the vendor lock-in is lot lower than with your typical open-source large dependency like React or Spring, and people are generally happy to accept that.
Graphql isn't that complex, not more complex than the widely accepted SQL schema + query.
Tooling is top-notch (Graphql-codegen, Apollo, Postman, Graphql playground), and is quite easy to use. Junior devs become up-to-speed with GraphQL a lot faster in my experience, because there is a lot more homogeneity in GraphQL while everyone implements their own flavor of REST
I'm curious, what tasks do you find more complex?
Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.
GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
It does not have to be a POST request or even HTTP. The point about the 200 status code is correct.
The confusion comes in when are talking about what happens at on the graphQL server and the calls it makes.
Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query.
All that was initiated by a single graphQL query (a single POST) from the client. What do you report back to the client if one out of the three server-side REST calls fails? Depending the schema, your initial query is still successful, it's just that one of the fields is empty or NULL (again depending on the schema). So that by any reasonable definition is still a 200. Even if all service calls failed, if your schema allows for fields to be empty or NULL, it can still be considered successful.
All that is to say that graphQL is not a replacement for REST, it's an enhancement that serves as a negotiable schema between client and service, a data orchestration layer that can stitch together multiple data sources into that schema, and as a pretty robust way to think about what to present to the user in error conditions since every field you want in your query, presumably, serves in the UI in some way. It gives you the tools to intelligently handle when those fields are not available.
You can do that with vanilla REST calls of course and roll your own solutions to the problems graphQL solves (or tries to solve).
I can do that in any Django view, REST or otherwise. How is that unique to Graphql? I really can't see what I gain. You define your response in Swagger or you do it in Graphql.
I was explaining why graphQL isn't a 1:1 replacement for REST because of that.
I feel like you are hearing an argument that I am not making. Use whatever tool is best for the job / infrastructure / business needs. If that's Django cool. GraphQL has its place too.
It sounds to me like you could benefit from some kind of codegen [1] to generate native language code out of graphql and checking the queries at compile/build-time instead of runtime.
GraphQL playground [2] might be a lower-investment tool to help you.
[1] In JS/TS GraphQL code generator is the standard: https://www.graphql-code-generator.com/ Other languages have similar tools.
[2] https://github.com/graphql/graphql-playground
Then everything is checked when building or directly in the editor.
because GraphQL APIs generally have much higher quality than REST-like HTTP APIs. Designing a proper RESTful HTTP API is actually much harder than the GraphQL one.
- GraphQL schemas confuse junior devs, higher entry level
Junior devs will learn whatever is used in the company. IMO the problem is with inertia by devs who are only experienced with REST-like HTTP APIs
- REST if you understand what you are doing ... can do the same
if you understand what you are doing ... you can do anything
- REST is better for error handling and tooling
I disagree: GraphQL has good tooling, and better error handling patterns. But yes it requires some upfront design.
That's not just in terms of idioms (which are useful for abstraction layer sake), but authorization, performance, all the sorts of things that are very known quantities, with extensive framework integration, in REST land. You get a lot farther with the wide ecosystem of tracing and monitoring tools, API gateways, authenticating proxies, all these API integration points and what have you in JSON api land.
In specific language ecosystems with a specific choice of tooling and libraries you can ultimately make good things happen, but it's not nearly as universal. Apollo is an obvious contender. I also like HotChocolate in the dotnet ecosystem.
There are definitely benefits. GraphQL having typed schematization by default is huge, and arguably that's the best feature. That's something you need to be more disciplined about in REST land (e.g. OpenAPI). But there's good tooling to be had on those fronts as well. Arbitrarily-shaped types definitely come with their own set of maintenance challenges versus more static DTOs.
P.S. HotChocolate's EFCore integration [0] is some of the coolest library tech I've seen. Thanks to C#'s builtin data projection functionality (via LINQ), it's able to automatically build a Hasura-style fully baked GraphQL API directly from your database domain model (which you can transform arbitrarily to limit / add additional functionality to via LINQ). It's still not my default choice in a new app, but if I were going to invest in GraphQL it's probably the strongest contender
[0]: https://chillicream.com/blog/2020/03/18/entity-framework
IMO code quality of projects using REST-like HTTP APIs is usually lower than the corresponding projects using GraphQL APIs. Just like some people do not care to learn Javascript properly because of its perceived simplicity, for the same reason they are also don't care to learn REST properly.
How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code? Does it have proper type definitions, or everything is of a type "string"?
If you are a Stripe you can design a perfect RESTful HTTP API, but for a smaller shop it's much easier to build a moderately good GraphQL API than a corresponding quality HTTP API.
GraphQL forces you:
EDIT: For me personally GraphQL was one of the triggers to start serious research on Software Engineering, Software Correctness and Code Quality.> How many of HTTP APIs have a corresponding OpenAPI spec? And if they have, is it actually kept in sync with the code
Umm what? Is this specific to NodeJS or something? Cause Django and DRF allow one to very easily and very quickly creating high quality REST APIs that are self-documenting and trivial to maintain. Pretty sure rails and go have similar packages and methods to allow for making excellent REST APIs. In fact I've found it a massive pain and a huge performance cost to add GraphQL to such projects. It's far slower than the REST calls
How on earth do you say, with a straight face, that the reason a task becomes more complex is because the API is "higher quality"? Higher quality in my mind coincides with ease of use, which is exactly where GQL falls down big.
https://news.ycombinator.com/item?id=27344552
Especially odd is the "scalability" remark, given those are protocols, they have no bearing on any aspect of the "scalability" of the implementation that I can think of.
Actually both SOAP and GraphQL are often used as aggregate endpoints for exposing internal APIs, often for the infrastructure of entire companies (see how GraphQL is used at Netflix for example). So they're predominantly used where you NEED scale, and REST fails them, due to the heterogenous nature of their clients (external and internal) vs. the "prebaked" structure of REST as a large-grain resource protocol (Fielding's words, not mine).
And the "companies that profit from complex solutions" is a rather poor theory. GraphQL was designed by Facebook, which doesn't profit from "complex solutions". Quite the opposite, they want APIs that are accessible both to their teams and the world. Same with Netflix. GitHub. Shopify. Airbnb. PayPal.
Where are those evil companies conspiring to profit from complexity?
oh they're entirely similar - overly complex data transfer schemes. They both also push too much responsibility on to the client. They also have steep learning curves.
It may have started at facebook, but the graphql industry has a life of its own now. I've seen this with many technologies. People start tooling and consulting companies around some technology and start pushing it hard. If it isn't needlessly complex, why does it have its own conference?
https://goodapi.co/blog/rest-vs-graphql
https://news.ycombinator.com/item?id=17565508
https://blog.hitchhq.com/graphql-3-reasons-not-to-use-it-771...
https://www.reddit.com/r/javascript/comments/ifxvo0/why_i_do...
REST is simple compared to GraphQL if you have no standards at all and just slap everything with ad-hoc CRUD resources at will. That's what you do, don't you?
Ever tried to implement OData or OpenApi or any kind of structured API covering HATEOAS at all? Do you actually define your own content types, with MIME and so on? My guess is no. You're not doing REST. You're doing JSON CRUD RPC.
REST is a quagmire of competing half-completed standards trying to do what GraphQL does in one step and with least amount of "maybe this maybe that" situations.
So how do you fix that? Well you’ve got to do query introspection to resolve certain queries in a more optimized way. Which tends to be more complicated than just…doing exactly what you want to do via a REST endpoint.
Now I’m not saying this isn’t worth it. In many cases it probably is assuming the people implementing your GraphQL server are competent engineers that will be able to optimize where it matters and make it scale. IMO it’s just worth recognizing that it does take more skill to implement a GraphQL server well.
Whether the introspection is hard or not depends on the library. A good library provides you with a set of queries sub-paths and then it‘s trivial to pre-fetch those at an outer resolver.
I wonder why this is even controversial now. APIs have been like that for about 15 years and GraphQL was created to address that and it does it very, very well.
edit: slver has explained my point of view much better than I have here.
- REST is standardized, because look at all the standards for it (OData, OpenAPI etc.).
- REST is easy, because I don't implement any of those standards.
- REST is flexible, because I don't even understand the constraints of REST and violate them at will turning it into RPC calls, thinking that it's about pretty URLs and CRUD verbs.
Honestly, it's pointless to argue with those folks. Let them believe REST is the solution. It's way above their paygrade to understand why GraphQL exists.
Look you can't argue REST is easy by defining REST one way, then argue it's powerful and has these features by defining it another way, and finally implementing it in a third way.
GraphQL at least has a shape. It's a thing. It says "you gotta do this and this and this, and then you get that and that and that out of it".
The original REST paper also has the same tit-for-tat proposition, but it was abstract, not a concrete architecture, rather it was an architectural style. And as such, it's been basically ignored. Oh, also the REST architectural style is NOT suitable for fine-grained data APIs (Fielding's words not mine).
When you say REST API today, REST is not a thing, it's shapeless, formless, it has no smell, no taste, you can't touch it. So newbies can claim it's easy because you just slap some JSON and you call it REST API.
No, GraphQL can't compete with that definition of REST. But also it's not trying to.
https://github.com/graphql/dataloader
You're talking about having a REST endpoint which has a "prebaked" aggregate query. But this is not plausible when you serve hundreds, or even thousands of heterogenous clients. Even big organizations like Netflix quickly gave up "prebaking" thousands of REST endpoints for every usecase they had across the organization and outside it.
And aggregate query resources are an anti-pattern in REST because it denormalizes the resources. You're supposed to have one resource on one URL. Instead of one resource included in hundreds of ad-hoc aggregate collections at other URLs, each of which are cached (and go out of sync) independently. And if you have one resource per URL... this creates the mother of all N+1 problems automatically.
It’s still easier imo to deal with that than the equivalent in GraphQL up to the point where you’re dealing with a large number of heterogenous clients as you describe. And that’s a problem a small minority of GraphQL users are facing or will ever face.
Where are your arguments? There are exactly zero and now everyone in the thread has to work to debunk these baseless claims.
There are exactly two almost valid points in here:
The default implementation has some overhead (for query validation). That may cause performance issues.
If you deliver public data where the full response can be cached, then REST makes that slightly easier (GraphQL discourages transport by HTTP GET).
I have worked with both for many years, GraphQL solves many real world problems. However you might only understand that as a full stack or frontend developer. If you only write APIs on the backend it appears pointless of course.
Though in my experience, it's a very small fraction of the actual processing time by Amdahl.
It depends on what you do. I worked on an application that could be cached heavily and got a very large number of requests and as a result the query parsing and validation mattered.
A new dev at my work is pushing for graphql, and I am sceptical. We have way to much complexity at present and it seems like a new less understood tech that is only going to increase complexity rather than reduce it.
Do you have any examples you are willing to share.
Can you implement this over REST? You can pretend you can, but if you put all those parameters in the URL and have countless ways of fetching the same data via infinite resource URLs, you're essentially bastardizing the concept of one URL one resource, or the idea that your entities each has its own URL, rather than inlining them in countless ways through one-off aggregate resources.
TLDR; REST really doesn't do what GraphQL does. And when you try to make REST do what GraphQL does, it ceases to be REST.
There's a fundamental data modelling issue that any relational-based system needs to address somewhere in the stack.
Data is stored in more than one table and that data often needs to be joined together for the frontend. Embedded REST apis have the same fundamental issue. That work is just "hidden" inside some sort of server side function.
----
Imo, GraphQL and REST face the same fundamental performance issues. The difference is GraphQL allows clients to optimize the data they need in the response. I'd you have a GraphQL performance issue, you'll likely have a similar or worse REST issue.
https://www.graphile.org/postgraphile/jwt-guide/
When it first came about it seemed like a band-aid to try and get around poorly designed REST systems so backend engineers wouldn't have to deal with frontend devs asking for data and new endpoints. I dunno if it's matured enough past that. Not saying REST is perfect and lord knows enough companies abuse it but a lot of stuff is pretty solved with simple, well documented solutions online