In what projects does it make sense to go for GraphQL

I wouldn't adopt any technology for my business because it's cool. Learning something new is putting speed bumps in your path.

With that said, I've been using GraphQL in production at my day job for 2 years. It's great for gluing together multiple REST APIs. You'll find a lot of client side developers love it too. There's a steep learning curve so make sure everyone is onboard with changing how they approach API design and development.

I think it depends on your data model. If you have a lot of entities and complex relationship between them, GraphQL make sense. If your app is more like a chat app with fewer entities, then it might not make sense.

My co-founder Derric wrote a very popular blog post on this topic:
(if you search for graphql vs rest on google, it is on page 1, since it is referenced a lot.)

https://www.moesif.com/blog/technical/graphql/REST-vs-GraphQL-APIs-the-good-the-bad-the-ugly/

I've just launched my first SaaS which is a GraphQL API for movies.

https://moviegraph.io

Initially I planned on just using REST endpoints, then I planned for a combination but eventually decided to just ship with a GQL endpoint. This was for 2 reasons:

1. I figured it separated me from the tons of competition.
2. It was actually a lot easier to implement than writing endpoints would have been.

There are hidden security and scalability risks when it comes to using GQL, too. In my case GQL is a starting point... if the project gets any traction I'll likely shift focus away from it.

I’m using GraphQL for both work and side-projects. Makes sense if:

1. You need flexibility/scalability in the feature
2. You care about payload size a LOT
3. You’ve got most of the resolvers for free (Prisma)
4. You want your code to be truly isomorphic, considering you are working on React.js project (with GraphQL it’s possible to use the same code for both client and server side without the need to write custom code to prefetch data for server side rendering)

From what I understand it's best used in cases where latency and network speed are a primary concern, such as for mobile apps. It's great for cutting down network requests by loading multiple resources in a single request. This is in contrast to REST where you typically have endpoints setup to handle different resources, so querying multiple things generally requires multiple requests.

I've not used GraphQL much, but that's my rough understanding of the core benefits.

I use it for my side projects. Go for it

I am using for my app. Specific use cases:

1. Speed up your mobile PWA; Graphql sends fewer requests than REST
2. GraphQL helps to deal with caching related issues.
3. Apollo specifically has more than just GraphQL goodies. Network retry, batching queries, offline support etc.
4. If you are using react, then you can also use apollo as local state management ( No redux , No mobx ).

GraphQL is better than REST in pretty much every dimension except for set up time and learning curve. It's a big departure from REST. There's a lot to learn and a lot of boilerplate code to write before you can even start writing simple queries against it. I don't like using it for indie hacking because it's much slower to get a functional prototype using GraphQL than going with REST.

This comment was deleted 4 years ago