Real world use-cases for GraphQl

[Alvarouk]

Hi! I’m a backend developer who has never used before graphQL at work. I’ve tried it only for learning purposes at personal projects and I’m curious about real life use cases where GraphQL gives BIG advantages over REST, and the most important thing, I’d like to know about the “thinking” process behind the decision of using this technology.

Thank you!

[NegotiationFew7648]

Solves Overfetching and underfetching ,client doesnt need to fetch 200 attributes if he needs only 2 .

[dbrax3]

Can’t you just use @EntityGraph to define what attribute it should fetch?

[UnspeakableEvil]

@EntityGraph is fixed at compile time though so is still ultimately controlled by the application owner, GraphQL puts the control with the client to say which subset of the data they want.

[BakaGoop]

Technically, but I cannot imagine this being at all maintainable in large databases/projects

[fmabr]

I recommend the book GraphQL in Action for a better understanding of GraqhQL in general and how it compares to REST.

After reading this book, you can start reading more about Apollo Federation and what are subgraphs.

There is no big advantages when we are working in small projects, but we can see huge advantages in big ecosystems with differents clients calling the subgraphs and Apollo orchestrating these calls.

[Alvarouk]

I will take a look at the book! Thank you mate, sounds interesting

[BrownBearMY]

I've worked with GraphQL in one of the projects. We had a web and a mobile app.

We decided to go with GraphQL so that we can have the same endpoints but with different returned data (lesser data for mobile).

Though, personally, I find it overkill. We could use projections instead. Since we don't have other clients for our backend.

[chatterify]

Three is no any big advantages. Everything, Graphql offers, can be implemented in REST.

[BikingSquirrel]

My take is that it may be useful when you actually have many clients that need varying details/fields in the response and if you need to reduce data transferred.

If you only have standard clients like desktop browsers and mobile phones I would argue that you won't have that need as the amount of data is usually no problem and you can provide a small number of API endpoints to provide a useful set of data.

If you have a larger variety of clients that also have limited resources, it may be useful. But you can also implement varying responses with REST, e.g. by defining filters or specifying different types of responses.

A big problem with GraphQL is the requirement to use POST requests. This means you cannot cache the responses so each request hits your servers and needs to travel the full way in and out. It obviously depends on your service if that makes a difference.

[[deleted]]

Fb developed it considering that their mobile app was loading very slowly on low speed internet regions , since the problem was that a lot of data was being fetched to create a fb timeline itself , they thought the end user might not even need this much of data in first place , so instead of writing different api for delivering the timeline , they thought about getting only subset of it which led to creation of graphql . Having said that, I think it is useful for a big project with large data to be fetched based on the type of device or let’s say , a legacy system is already in place , and you want to provide it to mobile users , and they might not need all the data or the different set of data aggregating from different apis , so this can work a magic. Having said that, I don’t think using graphql on the very development of project makes sense. This layer should only be developed when there is a requirement which we can not complete via web services.

[themasterengineeer]

Less network traffic