It's often said that GraphQL fixes the problems of under-fetching and over-fetching. But is that really the case? In theory, it sounds promising. I...
For further actions, you may consider blocking this person and/or reporting abuse
I'd like to start this with noting that I absolutely love GraphQL but it has it place and that place is not everywhere. I work as a staff engineer, team lead, and subgraph owner, at one of the largest federated GraphQL implementations to date at Walmart Global Tech.
Most of what you stated is pretty accurate from a front end perspective as you primarily focused on under/over-fetching but there are definitely ways to mitigate some of the headaches. You're type generation tooling is probably one of the best friends when consuming a GraphQL API but that relies on another important factor. Schema design.
Schema design can make or break a frontend engineer. The schemas are the gatekeeper to your sanity.
Federation:
And the list really goes on.
One of the things mentioned was the nullable fields. That is a very important part of schema design
Take an array definition in GraphQL (I'm doing this on my phone so please excuse any minor syntax issues if I miss an autocorrect)
This is a horrible array design here. It's a nightmare for the front end.
propName could have the following outputs:
A better practice would be to stick to the convention of:
Adding the ! after String and after the array means that propName must not be null (must return an array) and may be either an empty array or an array containing 1 or more strings.
That reduces us to the following potential outputs:
This is just one example but it makes a night and day difference to a front end developer.
Great response from someone with actual deep experience with this stuff - main takeaway:
"it has it place and that place is not everywhere"
I'm comparing it a bit with the NoSQL "hype" of a few years ago - once the hype was over, we were able to talk ask the question "which use cases does NoSQL fit, and which use case does it NOT fit?"
Turns out that in most cases you just want an RDBMS, and I guess the same goes for GraphQL - in most cases you just want simple REST, but that doesn't mean GraphQL is useless ... as always, use the right tool for the job!
You are 100% correct! At our scale, I couldn't imagine our front end teams being able to accomplish what we have using rest and still being able to maintain the allowable thresholds for downtime or production issues.
One of my personal projects, I opted for a combination of GraphQL and REST using NestJS with nuxt 3 for the frontend app.
Nuxt because I love working with Vue
Nest because I can get up and running quickly while keeping some modularity to easily remove one moservices create a separate service out of it (this is planned for the future)
REST because it works best for exchanging auth codes for tokens as well as receiving webhook events from my auth provider.
GraphQL for a few reasons:
Your NoSQL analogy is dead on!
Thanks ... those are great choices, I'm a Vue fan as well !
My main takeaway is "I'm doing this on my phone". I abandon anything I'm answering on my phone if it looks like I'll need more than a couple of sentences because it's such a painful process compared to using a real computer. Props.
I 100% agree with this. But you wouldn't believe how much I had to fight for the backend devs to adjust their practice accordingly.
And it's not just some random devs, I worked for a worldwide entertainment company that do business in pretty much every country in the world. Every damn backend dev I interacted with was screeching and wailing just at the idea of having to manage their types correctly in the response 🤷♂️
So, while you bring a lot of good points, and I do agree GraphQL is definitely not the problem in all situations, I can say with confidence that I would not recommend using GraphQL; Unless of course you are extremely strict on the typings, you manage to rein in your people and get them on the program.
My experience, which is only my experience, has been that devs are lazy. They will jump at every opportunity to avoid some work. Then slowly but surely, you're now managing a ton of typing idiosyncrasies in the frontend...
Unless you're transferring an extreme amount of data, the trade-offs are not worth it.
@TheThirdFace Fields are usually nullable in GraphQL schemas mostly to handle errors - the field will be replaced with a null if an error is thrown server-side. This is finally changing with the "semantic nullability" proposal. If that goes well (it's currently an experimental feature in Relay and I think Apollo too), I think the GraphQL best practices will change.
Hi @krd8ssb,
Thank you for taking the time to read my article and for sharing your valuable insights! I really appreciate hearing from someone with extensive experience in GraphQL, especially at the scale you're working with.
You're absolutely right—this article is heavily client-focused, and I agree that schema design is pivotal in GraphQL and can make or break the developer experience on the front end. However, some of the points I mentioned have roots in GraphQL's inherent design decisions and cannot be entirely solved through better schema design alone.
In my article, I aimed to highlight the reality of how many companies use GraphQL in practice, even when following best practices. To better illustrate this, I used some industry standard tools (like Hasura and GraphQL Code Generator) and avoided random GraphQL schemas and practices.
Also, poor schema design can indeed lead to issues like unnecessary nulls. However, even with a perfectly designed GraphQL schema, we still have to have nulls due to the inherent nature of dealing with I/O—as GraphQL's own best practices suggest.
I've tried my best to demonstrate that these problems are inherent in GraphQL's design and not merely the result of skill issues.
However, I still agree there can be way more benefits if we increase the scope beyond the client side only.
Your article was great and I don't disagree with you at all. You did a great job demonstrating a few of the pitfalls/difficulties experienced from the front end perspective. It is definitely not for everyone and every scenario. I find myself switching between REST, GraphQL, and GRPC depending on the systems or services I'm building.
IMHO, it comes down to understanding your tool kit and in knowing what tool to use for what job. The more you know about each, the better, quicker, and more confidently you can make your decisions.
Thank you for the write up!
Here, GraphQL. It does this:
Accurate one 🤣
There's nothing in the GraphQL spec that requires this behaviour... Blame whatever server-side library you use :)
Interesting read. I think both have their own merits (based on how huge stuff we are working on) but we often end up complicating things more than we realize. Still, companies like Medium use GraphQL for obvious reasons.
Man, I wish this were called out more often, and the examples you provide are first rate. Thank you for sharing! Bookmarking!
Nice article @frontendmonster! True, I agree. A nice solution to get the best of the both words is EdgeDB. Tried it in the other they and it's amassing how it works to be honest.
Thank you, very useful article!
Have you tried Relay? It solves most of the problems you've mentioned.
With Relay, you create one GraphQL fragment per component. The Relay compiler automatically generates either a TypeScript or Flow type for each fragment, and the
useFragmenthook will only return the fields that component asks for in its fragment. This means you're not passing down a loosely typed object. You still pass data via props, but each component only sees the data that it requests, not the data the other components need.For cache invalidation, Relay will automatically update its cache based on data returned from a mutation, even if it's just partial data (for example, if the mutation only updates one field, and only that field is in the query). Relay's cache is keyed by object ID (which is expected to be globally unique across your whole app) so it know the right cache entry to update. It also has strongly-typed optimistic updates, and even strongly-typed manual cache updates in the rare case that you need it.
Regarding nulls, it's being worked on as part of semantic nullability:
Relay (and I think Apollo?) have implemented the experimental
@semanticNonNullannotation, which make fields non-nullable if the only reason they can be null is due to an error (and errors will throw an exception client-side instead of nulling out the field).Thank you for sharing this! Yes, IMO Relay’s approach is "the" proper way to use GraphQL in components. However, for some reason, there seems to be an unwritten rule that Relay isn’t intended for the community. I’m not sure why I have this feeling, but I noticed Apollo and TheGuild solutions being used everywhere and Relay became an internal tool for Meta (like Flow).
I also wasn’t aware of @semanticNonNull. It looks like a game-changer—thanks for highlighting it!
I have to say, this article stated the issues that are quite valid, but I'm not seeing any solution, is it trying to say that the REST has no such issue? These are not the cost of changing from REST to GraphQL because all these issues happened in REST, so I think this is quite a bad article.
GraphQL at least gives the frontend developers a reliable data contract that we could use to do codegen with TypeScript, that single reason itself is powerful enough for every system to use GraphQL
Thanks for your comment! The article isn’t about promoting REST or denying its issues but rather highlighting what we need to sacrifice when adopting GraphQL, particularly on the client side. While GraphQL offers benefits like introspection and reliable type generation, these aren’t exclusive to GraphQL—technologies such as OpenAPI and Orval for REST or tRPC can provide almost similar type-safety and can be utilized in appropriate scenarios.
I used to work for a Fortune 500 and one of my tasks was building an API to serve current state data for IoT devices. The catches were that the devices were incredibly rich in the amount of information they would provide and creating new endpoints was a multiple team effort concerning API gateways and intermediary BFF APIs that would add context to requests.
The frontend needed something flexible to query information, layers of APIs away, that needed to be spun up in a short amount of time, support filtering, sorting, and pagination. We opted to build a REST API which ultimately behaved very similar to GraphQL. Everything was nullable because devices may not have reported any given property at any given moment. We built our backend in Java, so everything was strongly typed. We favored composition over inheritance but even so there weren't many levels of depth to the schema.
Looking back we could have definitely leveraged GraphQL, but it was a fun exercise in building something purpose built to behave like GraphQL. The hardest parts were safe dynamic query building and query complexity monitoring. In order to fetch our data we leveraged runtime reflection and a little bit of caching alongside it in order to determine if a provided filter was applicable to a given field based on the field's type. Each filter was then dynamically added to a query and provided inputs were sanitized and parameterized. Each requested property would add some level of complexity to the query which was completely tuneable. Same with filters and sorting. The more filtering and sorting requested, the higher the complexity score. At a certain threshold we would deny requests.
Overall, I'd agree with your position. GraphQL and one stop shops are hard to code and don't fit all cases, but in the cases where they make sense, boy do they save some work, and wow are they cool.
Your use case is why we created and open-sourced DB2Rest db2rest.com that automatically creates a REST API for your database and becomes an API gateway safely and securely. Responsibilities of data management are thus placed most effectively with the data team (DBA's, etc.) and querying, filtering is left to the frontend team where they don't even need to learn SQL because of DB2Rest's easy URL parameters syntax.
Just use Node interface and proper state management/cache, like Apollo cache. Problems you have are from lack of undestanding of GraphQL in its full power. No worries, it takes time! We are organizing GraphQL fe workshop if you would like to join.
There's a separate, extremely common problem that is related to this and affects a lot of the considerations in this article, which is that many web apps these days are loading way too much JS upfront and doing way too much work on the client. Even just choosing to use React in the first place (unless you have nothing but React server components) comes with a significant penalty for metrics like time-to-interactive. I realize it's an acceptable tradeoff for many apps because some are more performance-sensitive than others, but frameworks like React are really overkill for anything but a web app with a lot of very interactive components and dynamic updating. Now what does this have to do with GraphQL? Well, if you realize that all you really need is HTML and CSS for the initial page render delivered by presentational components, then you only need to request data on the client when you have an interactive component that needs to do an Ajax request in response to some user event, and in most cases you don't need some really complex GraphQL client in the browser like Apollo client. You can choose something lightweight like the npmjs.com/package/graphql-request, or you can have a thin server-side wrapper around your GraphQL API and just do regular GET and POST requests to your wrapper API. At my day job we use Remix, which still uses React, but Remix's loaders and actions essentially create this kind of thin GET/POST API, and so all GraphQL queries are actually executed on the server and we don't need to load a client-side GraphQL library at all, even for the interactive components that are rendered client-side.
Obviously this is different from how GraphQL is typically promoted to be used in a frontend web app, and you might think this defeats the purpose of using GraphQL in the first place, but I actually still see a lot of benefits of GraphQL in this scenario and I think those benefits can still apply to small or medium companies in many cases - but of course it depends on the use cases and REST could very well be a better option for some of those. This comment is already long so I'll hold off on going into further detail for now.