3 ms·
Hasura sure looks interesting, but two things make e hesitant: 1. The overly complicated schema it generates. For example, given an integer id, one can (and mu
by marton78 7y ago
Hasura sure looks interesting, but two things make e hesitant:
1. The overly complicated schema it generates. For example, given an integer id, one can (and must) use various operators to query that id, e.g. `user(id: { _eq(1) })` rather than just `user(id: 1)`, where other operators are `_gt`, `_lt`, etc. To make this possible, hasura defines a comparison object, which results in a very long schema. However, often the only comparison that makes sense is equality, e.g. for IDs, so this should be optional.
2. More importantly, using Hasura establishes coupling between the DB and the GraphQL schemas. What if at a later stage one decides to remove information from the DB and move it to an external source? GraphQL was designed to hide such implementation details. With Hasura this is no longer possible.
- pyankoff 7y agoRe 1: You can do `users_by_pk(id: 1)` for a while now.
- sbecker 7y agoRegarding your second point, I believe it is still possible to query an external source. Read the docs on “Remote Schemas” - https://docs.hasura.io/1.0/graphql/manual/remote-schemas/index.html https://docs.hasura.io/1.0/graphql/manual/remote-schemas/ind...
- indigo945 7y agoAnd anyway, if the database schema changes, unless for some reason the turnover is very fast, you can still manually offer views for clients that require the legacy schema.