4 ms·
Hasura is the best example I know of a beautiful, well engineered, well documented product that solves the completely wrong problem. It just converts a custom
by sgk284 7y ago
Hasura is the best example I know of a beautiful, well engineered, well documented product that solves the completely wrong problem.
It just converts a custom syntax represented in GraphQL into arbitrary SQL queries, which is absolutely absurd. They have mechanisms to restrict access, but the fundamental foundation of the idea is flawed.
GraphQL is great in that you define the exact queries that you know to be performant. Once you resolve your top-level payload, most of the nested fields will be non-parameterized relations. These are usually just tons of multi-gets.
So in practice, you have top-level queries that you know to be performant, followed by multi-gets that you know to be performant. If you do have a parameterized field, make sure it's fast.
- jacques_chester 7y ago> GraphQL is great in that you define the exact queries that you know to be performant. How is this meaningfully different from having an SQL query fronted by a REST API?
- WiseWeasel 7y agoGQL can return the top level query plus relations and any other entities needed for the view in response to a single request. The fact you don’t need separate requests or view-specific endpoints is significant.
- jacques_chester 7y agoRight, but if the answer to "it's too slow" and/or "it's too unpredictable" is "limit it to known queries", then ... how is that meaningfully different from known queries in SQL?
- ricardobeat 7y agoYou have control over what queries/entities get exposed in the graph. I think what he's saying is that most nested entities can be mapped to simple 'SELECT .. from .. where id = 1,2,3' queries, and a while a well-written JOIN might be more efficient, those have known performance and can benefit from caching, sharding etc.