4 ms·

Hasura is amazing, glad to see it featured here. The author never got around to any specific downsides (only a general complaint for some reason), does anyone h

Hasura is amazing, glad to see it featured here. The author never got around to any specific downsides (only a general complaint for some reason), does anyone have examples of where it struggles? I use it daily and have never run into a limitation.

Phlogistique 6y ago
I think the idea underlying this post is this: Sometimes you are creating an application and building its underlying datastore at the same time. Hasura is great for this. But sometimes you already have a disparate ecosystem of services and datastores and you want to provide a GraphQL API for that. This use case is better-served by other approaches.
- lowwave 6y ago
  And sometimes with nested GraphQL queries it just grind the db to a halt. It may be a good idea to convert it to SQL and optimized it by hand. Great tool. Personally I don't trust GraphQL completely.
  - praveenweb 6y ago
    In a production app, you would limit the query depth or have an allow-list to prevent arbitrarily nested queries.
    - andrewingram 6y ago
      Back in 2017 when I was doing a lot of work on optimising GraphQL, I briefly looked into how likely it was that a UI would actually end up requiring a query with problematic performance characteristics. The answer seemed to be “not very”. I had to come up with a deliberately contrived UI to find a realistic query that was more than 4 relationships deep. Most were around 3 (though double-nested connections were fairly common within this). The more common problem was around overall data size, where the bottleneck was JSON serialisation overhead and network transfer size. Query whitelisting is the winning approach for 1st party APIs. If you’re opening things up to third parties, e.g. the Github API, complexity analysis becomes the more valuable solution.
- tango12 6y ago
  On a related note, Hasura has Remote Joins which allow bringing different data stores, setting up "join conditions" and then being able to make queries that fetch data across those sources. Hasura then plans an execution which does a "push down" to the right source. For example, the database bits in so far as possible are compiled into a single SQL query and pushed down to Postgres. API calls are batched. You can join across Postgres, GraphQL and REST APIs. Scheduled for the 1.3 release this coming week!
  - chrisweekly 6y ago
    Cool!
- xuorig_ 6y ago
  Author here, thanks, that's exactly it ^
jakevoytko 6y ago
One example is interacting with complexity introduced by outgrowing a single database instance. This scaling could work a variety of ways. Records might be horizontally sharded across a bunch of database instances. Caching is layered above the database to protect against hot database queries, etc. The generation logic now needs to understand how to partition a single GraphQL query across the shards and caching layers. It's definitely not impossible, and in some circumstances it may be easy. But it couples your GraphQL implementation very tightly to your current database system in a way that may make it difficult to rearchitect your database system at the next order of magnitude scaling problem - "We really need to redo how we think sharding and caching, and our GraphQL's direct interaction with the data layer is going to make this a challenge." Maybe it's easier if the company is new and is GraphQL-only. An older company that has a mix of a few data access technologies might wish the GraphQL left the data layer concerns to the data layer.
- wdb 6y ago
  I understood Hasura is planning to support other databases to like Mongo and/or MySQL. If you run Hasura with something like AWS RDS most of your scaling issue on the data side is resolved. You can still run multiple instances of Hasura itself to horizontally scale it. Have to admit I haven't had this issue yet and I think it's a nice problem to have at that time as means too many paying customers :)
- tango12 6y ago
  We think about this at Hasura deeply! I know it's counter intuitive, but we think of this as an opportunity to solve those problems at the Hasura layer. Sharding and caching are hard but also not impossible to make declarative if you know enough about how the data is modelled, how data ownership works (authorization) and how the cache is managed (caching hot queries, caching complex queries but infrequent, invalidated on time or data). I'm not trying to say the problem isn't hard, I'm trying to ask what it would take to solve the problem. :) We're also actively working on solving them. Imagine if those challenges got solved for a sufficient number of use cases! Incidentally, databases are getting better at preventing users outgrowing them too while preserving the SQL API as much as possible, or providing a transform. Citus / YugaByte / Planetscale / Cockroach / Spanner to name a few.
polymeris 6y ago
I only evaluated hasura, haven't used it in production. What made me decide against it (it wasn't an easy decision, hasura does look cool) was the caching and scaling stories. The caching semantics for GraphQL are in general less mature than e.g. REST, but if hasura at least supported queries over GET it would help, by allowing CDNs to cache those requests. On the topic of scaling I was concerned that making a single postgres instance the bottleneck for the whole app does seem a bit of an expensive way to scale. But of course this all depends on the access patterns and the economics of the particular project.

Phlogistique 6y ago

I think the idea underlying this post is this: Sometimes you are creating an application and building its underlying datastore at the same time. Hasura is great for this. But sometimes you already have a disparate ecosystem of services and datastores and you want to provide a GraphQL API for that. This use case is better-served by other approaches.

lowwave 6y ago
And sometimes with nested GraphQL queries it just grind the db to a halt. It may be a good idea to convert it to SQL and optimized it by hand. Great tool. Personally I don't trust GraphQL completely.
- praveenweb 6y ago
  In a production app, you would limit the query depth or have an allow-list to prevent arbitrarily nested queries.
  - andrewingram 6y ago
    Back in 2017 when I was doing a lot of work on optimising GraphQL, I briefly looked into how likely it was that a UI would actually end up requiring a query with problematic performance characteristics. The answer seemed to be “not very”. I had to come up with a deliberately contrived UI to find a realistic query that was more than 4 relationships deep. Most were around 3 (though double-nested connections were fairly common within this). The more common problem was around overall data size, where the bottleneck was JSON serialisation overhead and network transfer size. Query whitelisting is the winning approach for 1st party APIs. If you’re opening things up to third parties, e.g. the Github API, complexity analysis becomes the more valuable solution.
tango12 6y ago
On a related note, Hasura has Remote Joins which allow bringing different data stores, setting up "join conditions" and then being able to make queries that fetch data across those sources. Hasura then plans an execution which does a "push down" to the right source. For example, the database bits in so far as possible are compiled into a single SQL query and pushed down to Postgres. API calls are batched. You can join across Postgres, GraphQL and REST APIs. Scheduled for the 1.3 release this coming week!
- chrisweekly 6y ago
  Cool!
xuorig_ 6y ago
Author here, thanks, that's exactly it ^

jakevoytko 6y ago

One example is interacting with complexity introduced by outgrowing a single database instance. This scaling could work a variety of ways. Records might be horizontally sharded across a bunch of database instances. Caching is layered above the database to protect against hot database queries, etc. The generation logic now needs to understand how to partition a single GraphQL query across the shards and caching layers. It's definitely not impossible, and in some circumstances it may be easy. But it couples your GraphQL implementation very tightly to your current database system in a way that may make it difficult to rearchitect your database system at the next order of magnitude scaling problem - "We really need to redo how we think sharding and caching, and our GraphQL's direct interaction with the data layer is going to make this a challenge." Maybe it's easier if the company is new and is GraphQL-only. An older company that has a mix of a few data access technologies might wish the GraphQL left the data layer concerns to the data layer.

wdb 6y ago
I understood Hasura is planning to support other databases to like Mongo and/or MySQL. If you run Hasura with something like AWS RDS most of your scaling issue on the data side is resolved. You can still run multiple instances of Hasura itself to horizontally scale it. Have to admit I haven't had this issue yet and I think it's a nice problem to have at that time as means too many paying customers :)
tango12 6y ago
We think about this at Hasura deeply! I know it's counter intuitive, but we think of this as an opportunity to solve those problems at the Hasura layer. Sharding and caching are hard but also not impossible to make declarative if you know enough about how the data is modelled, how data ownership works (authorization) and how the cache is managed (caching hot queries, caching complex queries but infrequent, invalidated on time or data). I'm not trying to say the problem isn't hard, I'm trying to ask what it would take to solve the problem. :) We're also actively working on solving them. Imagine if those challenges got solved for a sufficient number of use cases! Incidentally, databases are getting better at preventing users outgrowing them too while preserving the SQL API as much as possible, or providing a transform. Citus / YugaByte / Planetscale / Cockroach / Spanner to name a few.

polymeris 6y ago

I only evaluated hasura, haven't used it in production. What made me decide against it (it wasn't an easy decision, hasura does look cool) was the caching and scaling stories. The caching semantics for GraphQL are in general less mature than e.g. REST, but if hasura at least supported queries over GET it would help, by allowing CDNs to cache those requests. On the topic of scaling I was concerned that making a single postgres instance the bottleneck for the whole app does seem a bit of an expensive way to scale. But of course this all depends on the access patterns and the economics of the particular project.