Context
When I started developing, REST APIs were the go-to and became the de facto in all of my projects. Fast forward to early 2019, and I was introduced to my first GraphQL project. When I first saw a GQL implementation, I had plenty of bad things to say about it, most of them stemming from GraphQL being so different from what I had grown used to.
While I had a lot to say about GraphQL when I first used it, I have not created a new REST project since first being introduced to GraphQL.
My Reasoning
It's probably confusing why I continued to use GraphQL over REST. Even after being repulsed when seeing it implemented for the first time. But there are a few things that kept me around:
- GQL allows the client to ask only for the data it needs, eliminating under/over fetching data.
- Introduces easy client-side optimizations (Less data == Load Faster)
- Removes the need for API versioning as fields can be added and deprecated without affecting the client.
- Strongly typed, meaning you know what data is available and the type of data it is.
- Integrations with other services.
- The biggest one for me personally is the ability to take GQL projections and apply them to my MongoDB queries. This reduces the amount of data processed through the network and reduces the overhead of the queries.
- Subscriptions are fantastic and make introducing real-time data into your application easy.
- Apollo, yes, this library is one of the main reasons I still use GraphQL. Setup is quick and easy, comes with a great configurable caching system, handles errors, and plenty of other utilities, making the experience a lot nicer.
Your Thoughts?
Even though I use GraphQL, what are your preferences and thoughts on either technology? I would like to see other viewpoints on this topic, maybe even learn something new in the process.
Top comments (20)
GraphQL is the best way to avoid overfetching data and blocking the application from functioning properly
Is the overfetching or underfetching actually an issue with REST? REST also allows you to create Web APIs with queries. You can limit the requests to what you need.
Yeah but lets say i am fetching a collection of users from a database and lets assume we have 100 users so the app has to load and get all of the data and sometimes you may not need all of that data or only need a sub set of it with graphQL you can request what you want and you don't want
But why would you think this cannot be possible with a REST API? It is not unusal to be able to define queries, which can filter and order the results. Maybe you would like to have a look at OData as well. It is just a way to create these Web APIs and offers filters and more.
Well yeah but if you use graph QL it comes right out of the box and also it supports typescript so that a advantage so you can get types checking right out of the box
Maybe I am not understanding how GraphQL in general works, but REST is about how you create a Web API. If you are developing it, you will be able to implement it the way I have described.
What is in this case "Out-of-the-Box"?
Well.....you see in graphQL we can use types to performe a query which is a document high lighting all of the things you need from the db and typescript can be used to type that query document what way you know what data is what and where is it coming from and what are the type for example if a use the spaceX graphQL api i can use types to tell what the type is and thus getting better intellisense also in filtering in db the database is responsible for the filtering each item could be expensive with graph ql you don't need to do this
I generally take an SDL-first approach rather than write resolvers.
But also, I don't think about it as GraphQL VS REST, but instead think about GraphQL as a layer that connects data sources -- REST, dbs, other GQL APIs.
You might be interested in this cool little tool that the team I work with at StepZen put together -- it's gets a GraphQL API schema converted from a REST endpoint with a cli command stepzen.com/getting-started
That is a pretty cool tool, I'll be sure to test it out in the future.
I also like the sentiment of seeing GQL as a connection rather than a resource, kind of a good way to look at it. I still personally I believe them to be separate architectures with a lot shared similarities, but that gives me another way to view it.
Also I agree with the SDL-first approach. Even outside of GQL, I tend to always solidify my data structures first before moving into business logic.
REST is better for read-heavy, GraphQL for write-heavy applications. We've done a comparison for e-commerce applications:
aimeos.org/tips/graphql-vs-jsonapi...
Our decision was to continue to use REST or more precise JSON:API (jsonapi.org) for the frontend and GraphQL for the admin backend.
I am quite happy that i take the leap of faith before 5 years and i decided to invest my time to build my own graphql framework based on Code First approach instead of Schema First.
I called it @gapi stands for graphql api and it is written in typescript.
I have many modules in the system and also it uses Graphql Federation which combines all of the micro graphs into a big unified one.
github.com/Stradivario/gapi
If you are interested you can check the repository above.
The whole framework is battle tested in multiple production ready applications one of which is called
graphql-server.com
Cheers!
This is actually a good point. I have to agree, the support REST has is pretty great.
Also RBAC with GraphQL is awful... I have done it in two previous projects, and it was not a good time. I did learn a lot, and a few tricks which helped immensely the 2nd time implementing it (which was still terrible).
Something I really wish I had been more aware of when I opted for GraphQL over REST in my latest project is how prone to N+1 queries GraphQL can be due to generally how many backend GraphQL framework resolvers work, which can nullify any performance benefits. N+1 queries can definitely also be an issue with REST, but I've found it's much harder to avoid with GraphQL, particularly with any level of nesting or lists in your schema. Dataloaders are intended to resolve this, but IMO, they're a bit overly complicated and a fair bit of extra work to implement.
It also doesn't help that GraphQL is very JS-focused, so if you're using a different language to implement an API (I'm using python), there isn't a huge selection of tools and what is there is not great or very beta.
That said, I'd still make the same choice of GraphQL over REST if I were to choose. The flexibility is great, the introspection and typing make development that much easier, maintainability is easier, and overall feels like what an API should be.
Graphql is better for a large server and is easy and fun to play around with. I really enjoy playing with @replit 's graphql.
As for REST, it's a bit harder if you are playing around with it.
I am a Next.js fanatic so I use REST mainly for POST routes, but as for fetching data, I interact directly with the database via getServerSideProps.
I've recently been working on a NextJS/Apollo application, and so far really enjoying the environment. Have had a few hiccups, mostly reguarding authentication.
But any partiular reason you chose REST for POST (I assume write) routes?
In the project I'm working on, I use
mutationsfor any write operations, which instead of returning the data directly, I leverage the Apollo Cache to update the record, which is then propogated to my client. I took influence from their next-apollo example project.It depends on a few things.
If you don't have separate database contexts and want to load information for a list/table I tend to use graphQl. Otherwise REST
I’ve never tried GraphQL before, I’ve only heard about it lots of times, think it’s about time I start to look into it 😌…
Whats nice about graphql is that it becomes really easy to generate code to provide type safety on the frontend. For Rest thats a lot more difficult