We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1]<p>Overall the experience has been fantastic. The performance and authorization scheme is very good. It has allowed us to wash our hands clean of bespoke endpoint writing for our enterprise customers with complex integration requirements (for the most part... waiting on mutations!).<p>One thing I wish was handled differently would be Same Schema, Different Database support.<p>We have multiple multi-tenant databases as well as many single tenant databases. All share the exact same table structure. As it stands, we have to maintain a separate Hasura instance for each of these databases as the table names conflict and there is no way to rename or reference them differently. That leaves us with the minor annoyance of needing to instruct users on their appropriate server prefix (server1.fast-weigh.dev/graphql vs server2.fast-weigh.dev/graphql... etc). Yes, we could proxy in front of these and route accordingly. But that's just one more layer to deal with and maintain.<p>It sure would be nice to have a single instance to maintain that could handle database availability based on the role of the incoming request.<p>Even with the minor inconvenience of multiple instances, I 10/10 would recommend. It's a huge timesaver assuming you've got the data access problems it seeks to make easy.<p>[1]: <a href="https://fast-weigh.com" rel="nofollow">https://fast-weigh.com</a> / <a href="https://docs.fast-weigh.dev" rel="nofollow">https://docs.fast-weigh.dev</a>
I'm overall very impressed with Hasura, but have found it cumbersome to work with if using UUID primary keys because it won't map them as the GraphQL ID type [0]. There are plenty of people using Hasura successfully in production environments, so I'm curious how others handle it. I'm hoping the answer isn't "just use int PKs", but it'd be helpful to know if it is.<p>[0] -- <a href="https://github.com/hasura/graphql-engine/issues/3578" rel="nofollow">https://github.com/hasura/graphql-engine/issues/3578</a>
(Vamshi from Hasura)<p>We've been working on SQL server native support and we're happy to announce support for read-only GraphQL cases with new or existing SQL Servers.<p>Next up is adding support for stored procedures, mutations, Hasura event triggers [1] and more!<p>[1]: <a href="https://hasura.io/docs/latest/graphql/core/event-triggers/index.html" rel="nofollow">https://hasura.io/docs/latest/graphql/core/event-triggers/in...</a>
I've used Hasura for a couple of projects but I feel somehow and sooner rather than later, a requirement shows up that you an't really solve with Hasura. I don't mean oh this is a bit awkward in Hasura but rather this needs to be fully custom code exposing its own graphql (which Hasura would do an excellent job of stitching together). That being said some of the operational challenges with Hasura specifically metadata and migrations are better solved using other solutions.<p>Prisma when combined with Apollo on the other hand makes it easy to build GQL handler, which can handle strange requirements but also makes it easy to avoid Hasura induced awkwardness.<p>The Hasura team seems very component however and I hope they will work out these issues.
The space is def interesting and the product probably lowers the barrier to entry for development. My main question will be why would you use it against plain/open-source PostgreSQL RBAC + GraphQL server or something like <a href="https://www.graphile.org/postgraphile/" rel="nofollow">https://www.graphile.org/postgraphile/</a> ?
If you're into GO then there is GraphJin which can be used a standalone service or a library. Works with Postgres, MySQL and MSSQL soon. <a href="https://github.com/dosco/graphjin" rel="nofollow">https://github.com/dosco/graphjin</a>
Happy customer on Postgres who just signed a large contract that needs SQL support.<p>Love the product and the team, keep up the great work.<p>Out of curiosity is support for multiple roles in the works?
I am now building on Hasura. Love the experience overall, but some aspects are frustrating. For example, setting up authentication for a React Native (Expo) app with Auth0 is quite cumbersome, and the docs are a bit out of date.
If anyone at Hasura is reading this. Are there any plans to make poll frequency configurable on a per-query basis?<p>We have different queries with dramatically different latency requirements (e.g. 1 second vs 5 minutes vs 1 hour). Currently we are only using Hasura for the low-latency queries, and are falling back to polling for other things. But it would simplify our development model if we could just subscribe to these changes with a lower frequency.<p>If we could additionally have some kind of ETAG-style if-not-modified support when initialising connections, that would be extra amazing.
We literally had to rebuild an app because this support was so bad and they sold us on it being ready. Yikes.<p>It also needs its own PG db to function in order to support SQL Server.<p>PG usage was pretty good. Auth sucked.<p>Usage in CI pipelines is hot garbage. Command line tooling does not work well with it at all.<p>I'd probably take the risk again for a toy...maybe.
We've built and launched our community platform on Hasura + PG RDS. Row-level permission has been a time-saver to launch a product quickly. Stability has been great - our Hasura container hasn't crashed / restarted in the last 9 months.<p>Their are downsides (it has proven frustrating for us to implement the authentication part for a role that is not user or admin) but I would definitely recommend Hasura to experienced developpers.