9 ms·

Hasura GraphQL Engine and SQL Server

182 points by tango12 5y ago

vsurabhi 5y ago
(Vamshi from Hasura) 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/index.html https://hasura.io/docs/latest/graphql/core/event-triggers/in...
- CameronNemo 5y ago
  I know this may not be exactly on topic, but do you know when version 2 will be released? My team has been waiting on a single feature from that release for what seems like months (slack in jwt verification time, right now the clocks on our hasura and keycloak servers are off and it is creating issues).
  - tango12 5y ago
    Hey! We released 2.0-beta.2 this week and we're planning on releasing 2.0-stable on Mon/Tue. Sorry, I know it took a while, but we had to make sure we could make the upgrade path non-breaking given it was a massive release and this took longer than we expected! Please do feel free to reach out if you need any help with the upgrade :)
  - diveanon 5y ago
    How are you liking keycloak? Was evaluating it against cognito and auth0 last week.
    - CameronNemo 5y ago
      I don't use it directly, our systems engineers maintain and configure it. They had some trouble getting clustering to work for a while, but not sure if that was really the fault of keycloak.
diveanon 5y ago
Happy customer on Postgres who just signed a large contract that needs SQL support. Love the product and the team, keep up the great work. Out of curiosity is support for multiple roles in the works?
- tango12 5y ago
  Yes! We announced experimental support earlier and here's the new spec we're implementing that will support all databases and remote schemas too. https://github.com/hasura/graphql-engine/issues/6991 https://github.com/hasura/graphql-engine/issues/6991 General support for inherited roles is one of the things I'm most excited about because it makes a bunch of hard things around reusing and composition so easy. This improvement plays really well along with things like "role-based schemas" so that GraphQL clients have access to just the exact GraphQL schema they should be able to access - which is in turn composed by putting multiple scopes together into one role. Also interesting is how well this could play with other innovations on the GraphQL client ecosystem like gqless[1] and graphql-zeus[2] because now there's a typesafe and secure SDK for really smooth developer experience on the client side. [1]: https://github.com/gqless/gqless https://github.com/gqless/gqless [2]: https://github.com/graphql-editor/graphql-zeus https://github.com/graphql-editor/graphql-zeus
  - diveanon 5y ago
    Role inheritance will really simplify our permissions system, looking forward to seeing that go live. Those client libraries are interesting. We are using introspection queries and graphql-codegen to generate react hooks and typescript types for our schema and its working really well.
yevpats 5y ago
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 https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ ?
- blumomo 5y ago
  I considered Postgraphile for our company but picked Hasura. While PG has better extensibility, Hasura has a more polished unboxing experience and way lower learning curve. Time to market is crucial for us as we needed to prove our MVP.
- tango12 5y ago
  In general, and for SQL Server specifically, our intent was to add great support (low footprint, works out of the box) in a way that doesn't need DDL or write access to the underlying database. This becomes super useful for folks building new applications or new features against existing SQL Server systems (which is a rather large ecosystem beyond just the database, since so many products use SQL Server underneath too!)
- scoopertrooper 5y ago
  Both these projects support Postgres, have open source cores, and feature 'pro' options. https://github.com/hasura/graphql-engine/ https://github.com/hasura/graphql-engine/ https://www.graphile.org/postgraphile/pricing/ https://www.graphile.org/postgraphile/pricing/ https://hasura.io/pricing/ https://hasura.io/pricing/ (see: self-hosted) https://hasura.io/docs/2.0/graphql/core/databases/postgres/index.html https://hasura.io/docs/2.0/graphql/core/databases/postgres/i...
  - rattray 5y ago
    That's technically true, though Hasura is a well-funded startup with a $99+/mo cloud offering and Enterprise features while postgraphile is one main open-source developer who has support contracts available and accepts donations (the "pro" package is pretty minimal and costs just ~$25/mo). You can get started with Hasura for free which is great, and you can run it on your own servers (if you want to manage a Haskell service) which is also great, but in practice choosing Hasura means you're relying on a company for your backend and choosing postgraphile means you're relying on an express plugin which you can get a support plan for. I'm not saying one is the better choice than the other for this reason, many would prefer the funded company.
onebot 5y ago
How about build-in authorization for Postgesql?
- tango12 5y ago
  That already works! :) Postgres was the first database we added support for! https://hasura.io/docs/2.0/graphql/core/databases/postgres/index.html https://hasura.io/docs/2.0/graphql/core/databases/postgres/i...
- kall 5y ago
  I think hasura supports this? Or do you mean native postgres users with postgres RLS? The hasura team has explained somewhere why they don‘t want to do this. IIRC it had something to do with caching and/or subscriptions.
nicoburns 5y ago
If anyone at Hasura is reading this. Are there any plans to make poll frequency configurable on a per-query basis? 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.
- tango12 5y ago
  @nicoburns: Yes, this is something that we've been thinking about, but we haven't put a spec together yet. Could you open a github issue with a rough proposal of how you'd like to specify this information? For example: at a subscription level (with a directive or header), or via metadata built-on query collections [1] (what Hasura uses underneath for managing allow-lists). [1]: https://hasura.io/docs/latest/graphql/core/api-reference/schema-metadata-api/query-collections.html https://hasura.io/docs/latest/graphql/core/api-reference/sch...
- jensneuse 5y ago
  This feature is available with WunderGraph. You can configure Auth, caching, live query polling etc. at a global level and override it for each individual query: https://github.com/wundergraph/polyglot-persistence-postgresql-mysql-graphql/blob/84505032771b8293a46fbddc05b18f192ef9ba53/.wundergraph/wundergraph.config.ts#L35 https://github.com/wundergraph/polyglot-persistence-postgres... https://github.com/wundergraph/wundergraph-demo/blob/906f72cb19c22131dea960a28a8ee80bb8caff89/.wundergraph/wundergraph.config.ts#L141 https://github.com/wundergraph/wundergraph-demo/blob/906f72c...
  - dominotw 5y ago
    Looks like you are associated with wundergraph( based on your posting history here). Would you mind making that clear in your post given you are posting on a competitors HN post.
endisneigh 5y ago
How exactly is caching handled?
- tango12 5y ago
  Query-plan caching is built-in and here's a docs link for response caching: https://hasura.io/docs/latest/graphql/cloud/response-caching.html https://hasura.io/docs/latest/graphql/cloud/response-caching...
  - endisneigh 5y ago
    Is caching not available if you don’t pay?it seems that hasura cloud is a paid offering. It also doesn’t seem like it works with the self hosted offering. Any plans for that?
    - Dystopian 5y ago
      Caching isn't discouraged or disabled in any way in the community edition of Hasura. In terms of query-plan caching - which provides a lot of benefits for speeding up pre-query execution - that's already enabled by default as part of the Hasura engine. Response caching is a little more complicated and requires a separate service outside of the main GraphQL server to keep the solution generalized (ex. redis, memcached, lots of other options). We're definitely looking at ways to have some more examples as to how someone could go about rolling their own caching solution for self-hosted instances. In the case of hosted solutions to caching, there's Hasura Cloud which pairs the cache with monitoring and some other usability and security niceties - but you could also use a service like GraphCDN (there are a couple other as well) in front of your Hasura instance which helps setup response caching.
neural_thing 5y ago
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.
- tango12 5y ago
  Thanks! Could you point us to the docs you were looking at for the auth0 integration?
- dahdum 5y ago
  In your setup, Hasura is verifying a claim inside the JWT returned from Auth0 right? The only Hasura configuration I remember was setting the Auth0 public key and creating roles. I struggled with React/Cognito/AzureAD/Amplify but Hasura wasn't the pain point.
- notsureaboutpg 5y ago
  I built an Expo app on top of Hasura and rolled my own passwordless authentication mechanism and it was far far easier than using Auth0, imo. Auth was done using serverless functions to send emails with one-time-use tokens, to match the received one-time-use tokens with those generated in the database, and to return JWTs which the clients can use to auth later on and which grant access to different roles (it was an app with roles for managers, employees, etc.) You can even implement refresh token / auth token with rotation relatively simply. I felt Auth0 makes these things complicated to implement, whereas implementing them took only a few days and the docs / help online on how to do so are very good these days.
  - realce 5y ago
    I rolled a very similar solution with django+graphene+hasura
    - Dystopian 5y ago
      +1 that's probably my favorite way of doing it - https://github.com/martin-hasura/blog-django-graphql-hasura https://github.com/martin-hasura/blog-django-graphql-hasura Even Django REST Framework and Hasura works pretty well cause you get auth + then if you want to do functions you get that for 'free' as well
nerdywordy 5y ago
We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1] 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. [1]: https://fast-weigh.com https://fast-weigh.com / https://docs.fast-weigh.dev https://docs.fast-weigh.dev
- bpicolo 5y ago
  https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/ https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/ Multi-tenancy seems like their main 2.0 push
- piaste 5y ago
  > 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. We have the exact same scenario and solved in with the exact same workaround. As things stand, spinning up the Hasura instance is currently the last piece of the process we need to automate before we are fully able to onboard new clients without manual ops action. Hasura V2, currently in alpha, is supposed to support multitenancy as its flagship new feature. However, the "same object name in different database" issue is still open and on the roadmap, so presumably it's a _very_ early alpha.
nerdbaggy 5y ago
It’s pretty cool how Hasura uses/abuses Postgres JSON support to be able to run many queries in the same “command”
- tpetry 5y ago
  Can you elaborate on what they are doing?
  - simonw 5y ago
    I can take a guess. PostgreSQL's JSON tooling makes it much easier to build SQL queries that return different shaped data from different tables in a single query. The row_to_json() function for example turns an entire PostgreSQL row into a JSON object. Here's a query I built that uses that to return results from two different tables, via some CTEs and a UNION ALL: https://simonwillison.net/dashboard/row-to-json/ https://simonwillison.net/dashboard/row-to-json/ with quotations as ( select 'quotation' as type, created, row_to_json(blog_quotation) as row from blog_quotation ), blogmarks as ( select 'blogmark' as type, created, row_to_json(blog_blogmark) as row from blog_blogmark ), combined as ( select * from quotations union all select * from blogmarks ) select * from combined order by created desc limit 100 Even more interesting is what you can do with json_agg - it lets you combine results from other tables. Here's a demo that solves the classic problem of needing to include data from a table at the end of a many-to-many relationship (in this case the tags on entries on my blog): https://simonwillison.net/dashboard/json-agg-demo/ https://simonwillison.net/dashboard/json-agg-demo/ select blog_entry.id, title, slug, created, json_agg(json_build_object(blog_tag.id, blog_tag.tag)) from blog_entry join blog_entry_tags on blog_entry.id = blog_entry_tags.entry_id join blog_tag on blog_entry_tags.tag_id = blog_tag.id group by blog_entry.id order by blog_entry.created desc limit 10 (Both these demos use https://django-sql-dashboard.datasette.io/ https://django-sql-dashboard.datasette.io/ )
    - tehlike 5y ago
      this. JSON Agg fixes the cartesian product problem. Imagine having a table with large rows, and another table to join with small data but many rows. Normally you'd do a inner join of some sort, and the data from "large rows" would be duplicated many many times - json_agg simply fixes this. you can actually do the full table without json_build_object, too you can do something like select json_agg(t.) from ( select from table ) as t this makes joining multiple tables together very very easy, and performant.
npapag7 5y ago
In greek hasoura means loss
- cmrajan 5y ago
  I guess the name is play of words on Haskell (it's written on) + Sanskrit Asura (meaning demon)
- algorithm314 5y ago
  Yes indeed losing money :-)
nirvdrum 5y ago
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. [0] -- https://github.com/hasura/graphql-engine/issues/3578 https://github.com/hasura/graphql-engine/issues/3578
- steelbrain 5y ago
  I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?
  - the_arun 5y ago
    Why not use UUID as primary keys?
    - ddek 5y ago
      Can't speak for all dbs, but many use a clustered index on the primary key. In this case, the physical rows are stored in the order of the index, rather than just pointers to the rows. If you are inserting non-sequential data into a clustered index, every insert results in a non-trivial rearrangement of the rows. UUIDs are not sequential, so at scale you will experience performance issues if you are using UUID primary keys and the PK index is clustered. You won't notice this until significant scale, however. You can still use a unique identifier alongside an incrementing primary key, and you could choose to use a more compact format than the UUID. 8 base32 characters have over a trillion combinations, and are nowhere near as unsightly in a URL.
      - mping 5y ago
        Can't uuids be time based?
      - dragonwriter 5y ago
willeh 5y ago
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. 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.
- piaste 5y ago
  Hasura doesn't need to be your _only_ API. We use it as a time-saver for basic CRUD queries, but we do have a traditional REST webservice for everything else (in fact, Hasura was added later). Hasura just spares that backend code from being 95% soul-killing CRUD.
gip 5y ago
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. 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.
- diveanon 5y ago
  Do you mind explaining your role issue? We've been building out a pretty complex RBAC system and i might be able to help.
perilousacts 5y ago
We literally had to rebuild an app because this support was so bad and they sold us on it being ready. Yikes. 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.
gsvclass 5y ago
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. https://github.com/dosco/graphjin https://github.com/dosco/graphjin
navlelo 5y ago
How does this compare to Prisma?
- 2color 5y ago
  Check out this page in the Prisma docs: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-a-crud-graphql-api-without-writing-any-code https://www.prisma.io/docs/concepts/overview/should-you-use-... Hasura is great if you want to get a CRUD GraphQL API. Prisma on the other hand in an ORM that you import into your application code giving you more flexibility into the potential use-cases for it.
elwell 5y ago
Hasura + CLJS w/ Re-frame + WebSockets realtime subscriptions to GraphQL as EDN: https://github.com/Vetd-Inc/vetd-app/blob/cdac4d55f771b1928eeffb151372f643ea88f937/src/cljs/app/vetd_app/buyers/pages/product_detail.cljs#L226 https://github.com/Vetd-Inc/vetd-app/blob/cdac4d55f771b1928e...
shdh 5y ago
presence for subscriptions

182 points by tango12 5y ago

(Vamshi from Hasura) 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/index.html https://hasura.io/docs/latest/graphql/core/event-triggers/in...

CameronNemo 5y ago
I know this may not be exactly on topic, but do you know when version 2 will be released? My team has been waiting on a single feature from that release for what seems like months (slack in jwt verification time, right now the clocks on our hasura and keycloak servers are off and it is creating issues).
- tango12 5y ago
  Hey! We released 2.0-beta.2 this week and we're planning on releasing 2.0-stable on Mon/Tue. Sorry, I know it took a while, but we had to make sure we could make the upgrade path non-breaking given it was a massive release and this took longer than we expected! Please do feel free to reach out if you need any help with the upgrade :)
- diveanon 5y ago
  How are you liking keycloak? Was evaluating it against cognito and auth0 last week.
  - CameronNemo 5y ago
    I don't use it directly, our systems engineers maintain and configure it. They had some trouble getting clustering to work for a while, but not sure if that was really the fault of keycloak.

diveanon 5y ago

Happy customer on Postgres who just signed a large contract that needs SQL support. Love the product and the team, keep up the great work. Out of curiosity is support for multiple roles in the works?

tango12 5y ago
Yes! We announced experimental support earlier and here's the new spec we're implementing that will support all databases and remote schemas too. https://github.com/hasura/graphql-engine/issues/6991 https://github.com/hasura/graphql-engine/issues/6991 General support for inherited roles is one of the things I'm most excited about because it makes a bunch of hard things around reusing and composition so easy. This improvement plays really well along with things like "role-based schemas" so that GraphQL clients have access to just the exact GraphQL schema they should be able to access - which is in turn composed by putting multiple scopes together into one role. Also interesting is how well this could play with other innovations on the GraphQL client ecosystem like gqless[1] and graphql-zeus[2] because now there's a typesafe and secure SDK for really smooth developer experience on the client side. [1]: https://github.com/gqless/gqless https://github.com/gqless/gqless [2]: https://github.com/graphql-editor/graphql-zeus https://github.com/graphql-editor/graphql-zeus
- diveanon 5y ago
  Role inheritance will really simplify our permissions system, looking forward to seeing that go live. Those client libraries are interesting. We are using introspection queries and graphql-codegen to generate react hooks and typescript types for our schema and its working really well.

yevpats 5y ago

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 https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ ?

blumomo 5y ago
I considered Postgraphile for our company but picked Hasura. While PG has better extensibility, Hasura has a more polished unboxing experience and way lower learning curve. Time to market is crucial for us as we needed to prove our MVP.
tango12 5y ago
In general, and for SQL Server specifically, our intent was to add great support (low footprint, works out of the box) in a way that doesn't need DDL or write access to the underlying database. This becomes super useful for folks building new applications or new features against existing SQL Server systems (which is a rather large ecosystem beyond just the database, since so many products use SQL Server underneath too!)
scoopertrooper 5y ago
Both these projects support Postgres, have open source cores, and feature 'pro' options. https://github.com/hasura/graphql-engine/ https://github.com/hasura/graphql-engine/ https://www.graphile.org/postgraphile/pricing/ https://www.graphile.org/postgraphile/pricing/ https://hasura.io/pricing/ https://hasura.io/pricing/ (see: self-hosted) https://hasura.io/docs/2.0/graphql/core/databases/postgres/index.html https://hasura.io/docs/2.0/graphql/core/databases/postgres/i...
- rattray 5y ago
  That's technically true, though Hasura is a well-funded startup with a $99+/mo cloud offering and Enterprise features while postgraphile is one main open-source developer who has support contracts available and accepts donations (the "pro" package is pretty minimal and costs just ~$25/mo). You can get started with Hasura for free which is great, and you can run it on your own servers (if you want to manage a Haskell service) which is also great, but in practice choosing Hasura means you're relying on a company for your backend and choosing postgraphile means you're relying on an express plugin which you can get a support plan for. I'm not saying one is the better choice than the other for this reason, many would prefer the funded company.

onebot 5y ago

How about build-in authorization for Postgesql?

tango12 5y ago
That already works! :) Postgres was the first database we added support for! https://hasura.io/docs/2.0/graphql/core/databases/postgres/index.html https://hasura.io/docs/2.0/graphql/core/databases/postgres/i...
kall 5y ago
I think hasura supports this? Or do you mean native postgres users with postgres RLS? The hasura team has explained somewhere why they don‘t want to do this. IIRC it had something to do with caching and/or subscriptions.

nicoburns 5y ago

If anyone at Hasura is reading this. Are there any plans to make poll frequency configurable on a per-query basis? 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.

tango12 5y ago
@nicoburns: Yes, this is something that we've been thinking about, but we haven't put a spec together yet. Could you open a github issue with a rough proposal of how you'd like to specify this information? For example: at a subscription level (with a directive or header), or via metadata built-on query collections [1] (what Hasura uses underneath for managing allow-lists). [1]: https://hasura.io/docs/latest/graphql/core/api-reference/schema-metadata-api/query-collections.html https://hasura.io/docs/latest/graphql/core/api-reference/sch...
jensneuse 5y ago
This feature is available with WunderGraph. You can configure Auth, caching, live query polling etc. at a global level and override it for each individual query: https://github.com/wundergraph/polyglot-persistence-postgresql-mysql-graphql/blob/84505032771b8293a46fbddc05b18f192ef9ba53/.wundergraph/wundergraph.config.ts#L35 https://github.com/wundergraph/polyglot-persistence-postgres... https://github.com/wundergraph/wundergraph-demo/blob/906f72cb19c22131dea960a28a8ee80bb8caff89/.wundergraph/wundergraph.config.ts#L141 https://github.com/wundergraph/wundergraph-demo/blob/906f72c...
- dominotw 5y ago
  Looks like you are associated with wundergraph( based on your posting history here). Would you mind making that clear in your post given you are posting on a competitors HN post.

endisneigh 5y ago

How exactly is caching handled?

tango12 5y ago
Query-plan caching is built-in and here's a docs link for response caching: https://hasura.io/docs/latest/graphql/cloud/response-caching.html https://hasura.io/docs/latest/graphql/cloud/response-caching...
- endisneigh 5y ago
  Is caching not available if you don’t pay?it seems that hasura cloud is a paid offering. It also doesn’t seem like it works with the self hosted offering. Any plans for that?
  - Dystopian 5y ago
    Caching isn't discouraged or disabled in any way in the community edition of Hasura. In terms of query-plan caching - which provides a lot of benefits for speeding up pre-query execution - that's already enabled by default as part of the Hasura engine. Response caching is a little more complicated and requires a separate service outside of the main GraphQL server to keep the solution generalized (ex. redis, memcached, lots of other options). We're definitely looking at ways to have some more examples as to how someone could go about rolling their own caching solution for self-hosted instances. In the case of hosted solutions to caching, there's Hasura Cloud which pairs the cache with monitoring and some other usability and security niceties - but you could also use a service like GraphCDN (there are a couple other as well) in front of your Hasura instance which helps setup response caching.

neural_thing 5y ago

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.

tango12 5y ago
Thanks! Could you point us to the docs you were looking at for the auth0 integration?
dahdum 5y ago
In your setup, Hasura is verifying a claim inside the JWT returned from Auth0 right? The only Hasura configuration I remember was setting the Auth0 public key and creating roles. I struggled with React/Cognito/AzureAD/Amplify but Hasura wasn't the pain point.
notsureaboutpg 5y ago
I built an Expo app on top of Hasura and rolled my own passwordless authentication mechanism and it was far far easier than using Auth0, imo. Auth was done using serverless functions to send emails with one-time-use tokens, to match the received one-time-use tokens with those generated in the database, and to return JWTs which the clients can use to auth later on and which grant access to different roles (it was an app with roles for managers, employees, etc.) You can even implement refresh token / auth token with rotation relatively simply. I felt Auth0 makes these things complicated to implement, whereas implementing them took only a few days and the docs / help online on how to do so are very good these days.
- realce 5y ago
  I rolled a very similar solution with django+graphene+hasura
  - Dystopian 5y ago
    +1 that's probably my favorite way of doing it - https://github.com/martin-hasura/blog-django-graphql-hasura https://github.com/martin-hasura/blog-django-graphql-hasura Even Django REST Framework and Hasura works pretty well cause you get auth + then if you want to do functions you get that for 'free' as well

nerdywordy 5y ago

We have layered Hasura over an existing set of SQL Server databases to provide a public facing API for our product. [1] 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. [1]: https://fast-weigh.com https://fast-weigh.com / https://docs.fast-weigh.dev https://docs.fast-weigh.dev

bpicolo 5y ago
https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/ https://hasura.io/blog/announcing-hasura-graphql-engine-2-0/ Multi-tenancy seems like their main 2.0 push
piaste 5y ago
> 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. We have the exact same scenario and solved in with the exact same workaround. As things stand, spinning up the Hasura instance is currently the last piece of the process we need to automate before we are fully able to onboard new clients without manual ops action. Hasura V2, currently in alpha, is supposed to support multitenancy as its flagship new feature. However, the "same object name in different database" issue is still open and on the roadmap, so presumably it's a _very_ early alpha.

nerdbaggy 5y ago

It’s pretty cool how Hasura uses/abuses Postgres JSON support to be able to run many queries in the same “command”

tpetry 5y ago
Can you elaborate on what they are doing?
- simonw 5y ago
  I can take a guess. PostgreSQL's JSON tooling makes it much easier to build SQL queries that return different shaped data from different tables in a single query. The row_to_json() function for example turns an entire PostgreSQL row into a JSON object. Here's a query I built that uses that to return results from two different tables, via some CTEs and a UNION ALL: https://simonwillison.net/dashboard/row-to-json/ https://simonwillison.net/dashboard/row-to-json/ with quotations as ( select 'quotation' as type, created, row_to_json(blog_quotation) as row from blog_quotation ), blogmarks as ( select 'blogmark' as type, created, row_to_json(blog_blogmark) as row from blog_blogmark ), combined as ( select * from quotations union all select * from blogmarks ) select * from combined order by created desc limit 100 Even more interesting is what you can do with json_agg - it lets you combine results from other tables. Here's a demo that solves the classic problem of needing to include data from a table at the end of a many-to-many relationship (in this case the tags on entries on my blog): https://simonwillison.net/dashboard/json-agg-demo/ https://simonwillison.net/dashboard/json-agg-demo/ select blog_entry.id, title, slug, created, json_agg(json_build_object(blog_tag.id, blog_tag.tag)) from blog_entry join blog_entry_tags on blog_entry.id = blog_entry_tags.entry_id join blog_tag on blog_entry_tags.tag_id = blog_tag.id group by blog_entry.id order by blog_entry.created desc limit 10 (Both these demos use https://django-sql-dashboard.datasette.io/ https://django-sql-dashboard.datasette.io/ )
  - tehlike 5y ago
    this. JSON Agg fixes the cartesian product problem. Imagine having a table with large rows, and another table to join with small data but many rows. Normally you'd do a inner join of some sort, and the data from "large rows" would be duplicated many many times - json_agg simply fixes this. you can actually do the full table without json_build_object, too you can do something like select json_agg(t.) from ( select from table ) as t this makes joining multiple tables together very very easy, and performant.

npapag7 5y ago

In greek hasoura means loss

cmrajan 5y ago
I guess the name is play of words on Haskell (it's written on) + Sanskrit Asura (meaning demon)
algorithm314 5y ago
Yes indeed losing money :-)

nirvdrum 5y ago

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. [0] -- https://github.com/hasura/graphql-engine/issues/3578 https://github.com/hasura/graphql-engine/issues/3578

steelbrain 5y ago
I don't have an answer for you but you do have my curiosity. Why did you choose UUIDs as primary keys?
- the_arun 5y ago
  Why not use UUID as primary keys?
  - ddek 5y ago
    Can't speak for all dbs, but many use a clustered index on the primary key. In this case, the physical rows are stored in the order of the index, rather than just pointers to the rows. If you are inserting non-sequential data into a clustered index, every insert results in a non-trivial rearrangement of the rows. UUIDs are not sequential, so at scale you will experience performance issues if you are using UUID primary keys and the PK index is clustered. You won't notice this until significant scale, however. You can still use a unique identifier alongside an incrementing primary key, and you could choose to use a more compact format than the UUID. 8 base32 characters have over a trillion combinations, and are nowhere near as unsightly in a URL.
    - mping 5y ago
      Can't uuids be time based?
    - dragonwriter 5y ago

willeh 5y ago

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

piaste 5y ago
Hasura doesn't need to be your _only_ API. We use it as a time-saver for basic CRUD queries, but we do have a traditional REST webservice for everything else (in fact, Hasura was added later). Hasura just spares that backend code from being 95% soul-killing CRUD.

gip 5y ago

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

diveanon 5y ago
Do you mind explaining your role issue? We've been building out a pretty complex RBAC system and i might be able to help.

perilousacts 5y ago

We literally had to rebuild an app because this support was so bad and they sold us on it being ready. Yikes. 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.

gsvclass 5y ago

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. https://github.com/dosco/graphjin https://github.com/dosco/graphjin

navlelo 5y ago

How does this compare to Prisma?

2color 5y ago
Check out this page in the Prisma docs: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-a-crud-graphql-api-without-writing-any-code https://www.prisma.io/docs/concepts/overview/should-you-use-... Hasura is great if you want to get a CRUD GraphQL API. Prisma on the other hand in an ORM that you import into your application code giving you more flexibility into the potential use-cases for it.

elwell 5y ago

Hasura + CLJS w/ Re-frame + WebSockets realtime subscriptions to GraphQL as EDN: https://github.com/Vetd-Inc/vetd-app/blob/cdac4d55f771b1928eeffb151372f643ea88f937/src/cljs/app/vetd_app/buyers/pages/product_detail.cljs#L226 https://github.com/Vetd-Inc/vetd-app/blob/cdac4d55f771b1928e...

shdh 5y ago

presence for subscriptions