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/
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.
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/