by tango12 on 6/18/21, 10:57 AM with 83 comments
by nerdywordy on 6/18/21, 1:36 PM
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!).
One thing I wish was handled differently would be Same Schema, Different Database support.
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.
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.
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.
by nirvdrum on 6/18/21, 2:34 PM
by vsurabhi on 6/18/21, 11:08 AM
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.
Next up is adding support for stored procedures, mutations, Hasura event triggers [1] and more!
[1]: https://hasura.io/docs/latest/graphql/core/event-triggers/in...
by willeh on 6/18/21, 4:18 PM
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.
The Hasura team seems very component however and I hope they will work out these issues.
by yevpats on 6/18/21, 11:10 AM
by gsvclass on 6/18/21, 7:35 PM
by nerdbaggy on 6/18/21, 1:39 PM
by diveanon on 6/18/21, 11:09 AM
Love the product and the team, keep up the great work.
Out of curiosity is support for multiple roles in the works?
by neural_thing on 6/18/21, 12:50 PM
by nicoburns on 6/18/21, 11:42 AM
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.
If we could additionally have some kind of ETAG-style if-not-modified support when initialising connections, that would be extra amazing.
by perilousacts on 6/18/21, 7:28 PM
It also needs its own PG db to function in order to support SQL Server.
PG usage was pretty good. Auth sucked.
Usage in CI pipelines is hot garbage. Command line tooling does not work well with it at all.
I'd probably take the risk again for a toy...maybe.
by gip on 6/18/21, 6:55 PM
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.
by elwell on 6/18/21, 10:32 PM
by navlelo on 6/18/21, 7:40 PM
by onebot on 6/18/21, 11:14 AM
by endisneigh on 6/18/21, 11:51 AM
by npapag7 on 6/18/21, 2:03 PM
by shdh on 6/20/21, 7:00 AM