|
|
|
|
|
by rtpg
706 days ago
|
|
If your UI needs A and A.B and A.B.C, then you end up with three rest queries. Or you end up with some expansion logic. Meanwhile your REST query will likely also be throwing along for the write A.D, A.E, A.F, and maybe A.G.H because of some auto-expansion. > Unless you use and optimise for persisted queries which just makes it REST with extra steps. GraphQL offering a syntax and a way to state exactly what will be used makes it possible to chip away what is sent over the wire in persisted queries. This is not a negligable thing in environments with very wide and deep data models. These are places where their "REST" queries end up with "GraphQL with extra steps" through path inclusion/exclusion logic and expansion logic. Obviously at the end of the day context matters most, but there's been loads of places and APIs I've used where you could feel REST causing performance issues in an end-to-end way, either by generating N+1 HTTP queries, or just shipping way too much data to show a list of names of resources. |
|