GraphQL Conf. 2021
graphqlconf.org
graphqlconf.org
- 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.
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:
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.
> 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.
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.
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.
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
But 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)