|
|
|
|
|
by greatgib
983 days ago
|
|
For example, one promoted advantage of graphql is to be able to be more efficient by only requesting fields that you really need. But the reality is that it is often more costly to parse exactly what the client want and have graphql retrieve the whole data and decimate just the needed fields. And you don't even save bandwidth because a lot of metadata had to be transferred to do that. In a similar way, you will do one request, and the graphql server will have to trigger n requests to internal services.
Then you have things like having to wait for the slower service to be able to reply and display anything to the user, also having to still send n internal requests even if one of the first and important one would fail, like retrieving an user account. It will be harder to cache responses if the response content is specific to each request. A lot of things like that, where, in the end, you see that it is a lot more easier and efficient to have the client do generic individual api requests. |
|