DEV Community

REST API vs. GraphQL [comparison]

Duomly on September 09, 2020

This article was originally published at https://www.blog.duomly.com/rest-api-vs-graphql-comparison/ Into to REST API vs. GraphQL Si...

Read full post

Mirko Vukušić • Sep 9 '20

After many APIs built, I just tried Graphql (Postgraphile). First impression is that I dont think I'll ever want to program another Restful API. I allways liked database design, frontend too. Writing Restful was boring but necessary work. Id do it impatiantly between writing a database and frontend. On this project, it seems I jumped straight from DB to frontend. I absolutely love it that source of the truth is now DB. Even comments there transform to Type comments using codegen. Roles, permissions, almost everything. Loving it so far.
Ill see about other aspects, but for coding itself Graphql (although with Postgraphile), is a clear winner.

Gerard Klijs • Sep 10 '20

Your very short on the GraphQL part. There are some disadvantages compared to REST. For example authentication can be done, but there is no standard way of doing it. Which might mean additional work for clients.

But GraphQL has introspection, which mean you can ask the endpoint which data it can give back, and which queries it has. The best thing is this is on the same endpoint. While similar solutions exist for REST, like Swagger, it's not as usable. And a lot of libraries can use the introspection to generate code.

Another you didn't mention is that GraphQL supports streaming data with subscriptions, altrough its not easy to implement correctly. Especially scaling is hard, and there are some discrepancies between servers and clients on the specifics.

Sathish Ramani • Sep 22 '20

Nice article! I don't have much experience with REST / GraphQL. Recently, working on defining and calling gRPC APIs. I find it very good. GraphQL looks similar in some aspects (like typed, schema...etc.). Being a long time C Programmer, I would prefer gRPC, GraphQL type of things over the REST & JSON :-).

Muhiminul Islam Sabic • Dec 4 '21

I'm not sure what you meant by "In REST API, it’s impossible to get just needed data". We can create separate endpoints for those tasks. As far as I know, we can use GraphQL to limit the number of endpoints which will help us to cut the maintenance costs for separate endpoints.

Sm0ke • Sep 9 '20

Thank you! This is quite a nice content.

Duomly • Sep 9 '20

Thanks :)

WebsiteMarket • Sep 14 '20

NIce ...

PHAT DANG MINH • Sep 12 '20

thanks

Anzhari Purnomo • Sep 9 '20

What I still don’t understand: why does authentication in graphql considered a mutation? I mean, authentication does not save any data to the data persistence layer.

Sebastian Vargr • Sep 10 '20 • Edited

Maybe i do not understand the question correctly. :)

But GraphQL is just a query language.
Think of DB connections, you authenticate, and then you query, they are separate steps. :)

In practical GraphQL context, that usually means authentication headers and belongsTo DB relations in the models.

Anzhari Purnomo • Sep 10 '20

Hi Sebastian! Thank you for starting the discussion!

Adding more context into the question, what confuses me are why some library (e.g. Django GraphQL JWT django-graphql-jwt.domake.io/en/la... and Apollo Server apollographql.com/blog/setting-up-...) implement the TokenAuth as a mutation (mutation as in GraphQL mutation operation) instead of a GraphQL query operation.

What I understand from the term is "mutation" means change in the data. A TokenAuth operation to generate JWT shouldn't mutate any data, only checking the credentials provided whether it is valid or not, which should be more appropriate to use "query" operation instead.

Update:
Found the answer from here: stackoverflow.com/questions/501893...

An excerpt:

In the context of that example, login should be a Query instead of a Mutation assuming its resolver has no side-effects, at least according to the spec. However, there's a couple of reasons you probably won't see that done in the wild:

If you're implementing authentication, you'll probably want to log your users' account activity, either by maintaining some data about login/logout events or at least including some sort of "last login" field on the account's record. Modifying that data would be a side effect.

A convention has evolved that treats any operations that result from user actions as Mutations, regardless of side-effects. You see this with react-apollo, for example, where useQuery fires the associated query on mount, while useMutation only provides a function that can be called to fire that query. If you're planning on using Apollo client-side, it's worthwhile to consider those sort of client features when designing your schema.

Mutations are ran sequentially, while queries are ran simultaneously. That means it'd be foreseeable to fire a login mutation and one or more other mutations after it within the same call, allowing you to utilize an authenticated context for the subsequent calls. The same could not be said for queries -- if login is a query and you include other queries with it in the same operation, they will all begin resolving at the same time. Outside of how they're executed (sequentially vs simultaneously), on the server-side, queries and mutations are effectively interchangeable. You could have queries with side-effects and mutations with no side effects. You probably should stick with conventions, but I think sometimes there's valid reasons where you may have to throw those conventions out the window.

Arc • Sep 9 '20

Thank you! Great comparison😊

Thotho Haithem • May 27 '21

Thanks <3

Andrew Baisden • Sep 12 '20

I remember when I first learned GraphQL a few years ago before it became popular. I had an interview at a tech company and they had never even heard of GraphQL 😂