From time to time, some articles like [GraphQL: from delight to disappointment] appear(https://habr.com/ru/articles/728476 /). Since I actively use GraphQL and I’m not going to give up, I want to clarify my position.
If we talk about the article itself, then one of the main problems is the use of JavaScript/TypeScript on the server. In particular, it turns out not the advantage of typing, but rather the torment. I will discuss the topic of platform selection in more detail in the note Choosing among server application development platforms. Next, about GraphQL.
GraphQL is good precisely for the freedom of UI developers (web and mobile) to change the UI with less dependence on server programmers. And this is necessary not only in “big” projects (as most commentators point out), but also in small ones - it can be even more difficult to find programmers’ time there. All other advantages (such as fewer requests or traffic) are of little importance for startups.
GraphQL on the backend is no more complicated to implement than a regular HTTP request. Yes, you need to implement your own pagination, caching, etc. at the query level (if necessary), but you need to do the same in HTTP. If you need the reverse proxy to cache the response, then you need to either configure it or use HTTP. If you need the browser to cache the response, then you need to use HTTP.
The first implementation on the client is a bit more complicated, because you need to write a GraphQL query and generate the implementation. However, it is the mobile and web developers behind GraphQL. Why is that? Because then you will definitely need to make changes, and with GraphQL it is noticeably easier.
GraphQL is not some kind of silver bullet. Moreover, it cannot replace regular HTTP requests. Nevertheless, it is useful.
Several principles of working with GraphQL:
- GraphQL is not a replacement for HTTP. Use it where it gives advantages (data queries). Do not use it where it does not give. It’s very corny, but they often want to completely replace regular HTTP. Examples where you do not need to use graphql:
- uploading files to the server 2. Downloading files (especially pictures)
- Integration APIs (server-to-server)
- It is better not to use various third-party additional tools, services and libraries – in general, it is simply not necessary (KISS). These are Federation, Stitching, gateways, etc. Perhaps one day it will be necessary to do this, but then the project will be of such a size that specially trained people will do it.
- Whether to use mutations in graphql or not is a matter of style (and the quality of integration of the http specification on the server and clients) – http will be more convenient for someone, graphql for someone, but graphql does not give any special advantages here.
- Install the extension for Chrome GraphQL Network Inspector to conveniently view GraphQL queries.
- Install GraphQL plugin for Idea to make it easier to work in the editor.
- Code First or Spec First approaches are not so fundamentally used, as it is important that there be automatic generation. For example, in Spring Data, by default, they supposedly offer Spec First, but code generation does not occur - this is a problem (you need to write spec and code 2 times, and then at the start it will be combined or not). At the same time, there is a SQPR (Code First) option, but it does not support coroutines and is generally in some kind of rudimentary state (here Quarkus still looks better than Spring).
- Code First is usually better: the scheme is described in the main language. Plus, there is no code generation stage - assembly is faster.
- Authorization via headers: there are no restrictions in the specification itself, but we can authenticate through request headers as usual (whether it’s a cookie or an x-api key), and then, knowing the user, do authorization – again, nothing new about http.
- Pagination is done through request parameters – nothing new about http.
- The concept of errors exists in GraphQL. From project to project, it depends on which errors to take to which level: http, GraphQL, request response.
- If in the end some query slows down, then server developers connect and write a new specialized query (in GraphQL terms). Either completely new, or part of the query is being optimized. Yes, there is no magic, just routine.
As a result, GraphQL is an excellent tool for fast and independent (by clients) project development. At the same time, it complements the existing tools, rather than replacing something.