3 ms·
> But the most important thing you get with GraphQL is batching. Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing. Re
by loosescrews 4y ago
> But the most important thing you get with GraphQL is batching.
Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing.
Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using).
- kortex 4y agoI believe by batching they mean operating on collections of entities instead of single ones. So you may have POST /pets to create a single pet from a json object, but what if you want to add a hundred pets at once? Even with multiplexing, this is often way less efficient. Often the solution is to have POST /pets/bulk which takes a list of objects.
- nogridbag 4y agoI suppose it depends on the domain, but in all the APIs I've created bulk operations are fairly rare. I guess if you know upfront that your API would involve heavy bulk operations then seeking a tool that makes that more performant would be beneficial.
- aleclm 4y ago> Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing. HTTP/2 helps with the network layer, but your backend will still handle requests one-by-one. Depending on what you need to do, this might make a hell of a difference. > Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using). There's this: https://www.graphql-code-generator.com/ But yeah, on a second look I expected to find more. Anyway, having a standard way to do things instead of relying on one specific piece coupled to some language (swagger), it's certainly better. On the other hand REST APIs have a much longer history, so I guess it's normal for them to have more tools.