1

I have been reading about the articles on the web about the benefits of graphql but so far I have not been able to find a single benefit of it.

One of the most common benefits mentioned in those articles are below?

  • No Overfetching with GraphQL.
  • Reducing number of calls made from client side.
  • Data Load Control Granularity
  • Evolve your API without versions.

Those above all makes sense but it is not the graphql itself that provides these benefits. Any second layer api written in java/python or any other language would be able to provide this benefits too. It is basically introducing another layer of abstraction above the data retrieval systems, rest or whatever, and decoupling the client side from that layer. After you do that everything you can do with graphql can also be done with any other language too.

Anyone can implement a say scala server that retrieves the data from various api's integrates them, create objects internally and feeds the client with only the relevant part of the data with total control on the data. This api can be easily versioned and released accordingly. Considering the syntax of graphql and how cumbersome it is and difficulty of creating a good cache around it, I can't see why would you use it really.

So the overall question is there any benefits of graphql that is provided to the application because of the graphql itself and not because you implement another layer of abstraction between your applications and your api's?

ralzaul
  • 4,280
  • 6
  • 32
  • 51
  • Does this answer your question? [Are there any disadvantages to GraphQL?](https://stackoverflow.com/questions/40689858/are-there-any-disadvantages-to-graphql) – Michael Freidgeim Jul 25 '20 at 06:26

2 Answers2

3

Best practices known as REST existed earlier, too.

GraphQL is more standarized than REST, safer (no injections) and syntax gives great flexibility in the area of quickly changing client needs.

It's just a good standard of best practices.

xadm
  • 8,219
  • 3
  • 14
  • 25
  • Yeah, I can't think of too many libraries you couldn't say this about. – Raydot Oct 05 '18 at 17:41
  • REST has a totally different focus than GraphQL. While the latter is basically a kind of SQL slang for Web queries, the former one is a design principle in order to decouple clients from servers which allows servers to evolve freely withouth breaking clients. This, however, is only possible if certain constraints and steps are carefully followed. Also, there is no I'll do it just half-way in doing REST as otherwise the decoupling wont be achieved. GraphQL on the otherhand uses typed resources and therefore couples tightly to them – Roman Vottner Oct 05 '18 at 18:49
  • I would say it has parallels in its code structuring that e.g reminds me of REDUX or redux-toolkit in react.js. It just has certain standard defined fields so that you can reach certain goals in a safer way, but that also bloats your code. Otherwise, I also can't see any benefits, as you could always just transmit a granular sql query directly to your database and return the results that fit... – MMMM Oct 06 '21 at 17:22
0

I feel GrapgQL is another example of overengineering. I would say "Best standards and practices" are "Keeping It Simple."

Breaking down and object and building a custom one before sending it to the client is very basic.

Aaron Smith
  • 11