Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
I would say GraphQL has way more disadvantages over REST.
The inability to cache results (or if you manage to do so with forward caching proxy with lots of RAM and added latency) makes this only solution for systems that need no performance or scaling. Systems with hundreds, thousands or more clients or requests/second will suffer greatly and trash your cache by storing non-reusable GraphQL results.
GraphQL will more likely result in poor database performance as there is no way to optimize for all combinations of all database columns by indexes. Either you create wide tables (by de-normalizing them) covering every possible column combination by an index causing heavy disk usage and your database INSERTs to take seconds instead of milliseconds or you normalize your database and cause tens or hundreds of JOIN operations. In either case there's no optimization possible with GraphQL as the model is created at the front-end without back-end developer interaction and his/her possibility to optimze for performance.
Since support for HTTP Push in HTTP/2 and HTTP/3 is now killed in the RFC draft your options for size and performance optimized REST calls are basically sparse fieldsets or for better cacheability partials.
I am not sure about what you said, in this repository we have cache on graphql : github.com/graph-gophers/graphql-go , it is not about topology , it is about the package that you are using.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Do you have stats about hit ratios on your cache? It's most probably trashing. It's enough to swap 2 fields in a model or leave one out and you cannot reuse the cache. Also if you accidentally do not keep the order of fields as they are defined in the database index or add one extra field you cannot use the index and you pay by slow table scan performance. What's the point giving someone all the possible flexibility on the fronted when it results in 99.9% times in performance issues?
I got your point, maybe you can not cache everything 100% because of the huge data in queries, but it is not because of the topology of Graphql. graphql.org/learn/caching/
Just to chip in on caching, caching seems to work here over at Spotify and we get a decent amount of requests/second. It's not perfect though and i's not straightforward but you can get somewhere with query hashing for instance.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
hmnn im not sure, i think caching is mainly handled through its subsidiaries, so cant say to be sure. Bigger issue seems to be fanning out for requests, as one graphql request can potentially mean a lot of subsequent requests fanning out over multiple microservices.
Currently developing futuristic smart-device, IoT connected, highway construction site safety system in EU.
Used to work on infrastructure, application architecture and cloud engineering.
Statistically as tiny as 5 column table (with 4 really usable columns as one of them is typically an identifier) has 120 (5 factorial) different ways to order columns in GraphQL query that produces 120 different cacheable queries with identical result that would in normal case be cached and reused but now is trashing your cache. This becomes more prominent in bigger team where everyone writes their own queries.
thats very academic, but just don't do that then. i haven't seen an impact yet on our side, but what you are saying is probably true, sounds like the caching approach should be different, e.g. order on the fly. not saying its not a problem, i'm just saying were not having that problem, yet.
Or actually thinking about it, sounds like maybe caching in the wrong place, just cache the most used case and then sort on all the results? Otherwise i guess yeah you would need to cache for all those cases, taking up space.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would say GraphQL has way more disadvantages over REST.
The inability to cache results (or if you manage to do so with forward caching proxy with lots of RAM and added latency) makes this only solution for systems that need no performance or scaling. Systems with hundreds, thousands or more clients or requests/second will suffer greatly and trash your cache by storing non-reusable GraphQL results.
GraphQL will more likely result in poor database performance as there is no way to optimize for all combinations of all database columns by indexes. Either you create wide tables (by de-normalizing them) covering every possible column combination by an index causing heavy disk usage and your database INSERTs to take seconds instead of milliseconds or you normalize your database and cause tens or hundreds of JOIN operations. In either case there's no optimization possible with GraphQL as the model is created at the front-end without back-end developer interaction and his/her possibility to optimze for performance.
Since support for HTTP Push in HTTP/2 and HTTP/3 is now killed in the RFC draft your options for size and performance optimized REST calls are basically
sparse fieldsetsor for better cacheabilitypartials.I am not sure about what you said, in this repository we have cache on graphql : github.com/graph-gophers/graphql-go , it is not about topology , it is about the package that you are using.
Do you have stats about hit ratios on your cache? It's most probably trashing. It's enough to swap 2 fields in a model or leave one out and you cannot reuse the cache. Also if you accidentally do not keep the order of fields as they are defined in the database index or add one extra field you cannot use the index and you pay by slow table scan performance. What's the point giving someone all the possible flexibility on the fronted when it results in 99.9% times in performance issues?
I got your point, maybe you can not cache everything 100% because of the huge data in queries, but it is not because of the topology of Graphql. graphql.org/learn/caching/
I'd also add:
It puts too much logic and control on the client / UI.
Just to chip in on caching, caching seems to work here over at Spotify and we get a decent amount of requests/second. It's not perfect though and i's not straightforward but you can get somewhere with query hashing for instance.
Out of curiosity, how much dedicated cache storage your typical GraphQL cache server has?
hmnn im not sure, i think caching is mainly handled through its subsidiaries, so cant say to be sure. Bigger issue seems to be fanning out for requests, as one graphql request can potentially mean a lot of subsequent requests fanning out over multiple microservices.
Statistically as tiny as 5 column table (with 4 really usable columns as one of them is typically an identifier) has 120 (5 factorial) different ways to order columns in GraphQL query that produces 120 different cacheable queries with identical result that would in normal case be cached and reused but now is trashing your cache. This becomes more prominent in bigger team where everyone writes their own queries.
thats very academic, but just don't do that then. i haven't seen an impact yet on our side, but what you are saying is probably true, sounds like the caching approach should be different, e.g. order on the fly. not saying its not a problem, i'm just saying were not having that problem, yet.
Or actually thinking about it, sounds like maybe caching in the wrong place, just cache the most used case and then sort on all the results? Otherwise i guess yeah you would need to cache for all those cases, taking up space.