Hacker News new | past | comments | ask | show | jobs | submit login

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.




> 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?


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


Right, 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?


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: