Hasura Team Q&A on Reactiflux: Questions & Notes

The Hasura Team (Tanmai Gopal, Praveen Durairaju and Jesse Martin) took part in the latest Q&A on Reactiflux and we had a lot of interesting questions from the community. We have handpicked the ones related to Hasura and featured them in this post. Not surprisingly, we have gotten questions around the naming history of Hasura, which brings a smile :)

You can read the full transcript from the official reactiflux channel.

Question: How can I build a custom GraphQL query using raw SQL in hasura? – Aki

If you have a raw SQL query and want that to be exposed as a GraphQL query, you can either create a Postgres View or create a Postgres Function and expose it as a GraphQL API to the client.

Question: What do you see as the perfect positioning of Hasura in the overall infrastructure? e.g. use it directly as backend, or place a backend between it for handling logic, authentication, etc. In the same manner, what would you consider the perfect "Hasura-stack"? – mees

Good question! I'd say it's really up to you. 🙂 We're building Hasura so that it can be the frontend / recipient to API consumers directly. However if you prefer having something in the middle, that's totally fair as well 🙂

Choosing a good Hasura stack depends on one of 2 use-cases:

1. Is your end deliverable an API?
2. Is your end deliverable an app?

I like a serverless stack for the logic/authz backend piece.

So something like AWS Lambda (or choose your fave serverless function vendor) + Hasura + Postgres DBaaS + (choose your fave authn SaaS vendor) would be my recommended Hasura stack!

Question: What other services are competition to Hasura? And how do you differ with them? – f8_overcomer

While there's no direct equivalent to Hasura, there are perhaps 3 main types of services/technologies that Hasura overlaps with:

1. BaaS type products: Here Hasura's edge (and also downside in a way depending on what you want!) is that it doesn't take opinions on other things like storage, authn and is designed to provide the data API on new or existing databases. Today with Postgres-family / SQL Server / BigQuery and gradually with other popular databases as well. This is very impactful esp for teams that already have databases
2. GraphQL databases: We're gradually seeing databases that natively speak GraphQL becoming popular! This is awesome. Here Hasura's edge over them, is that a) Postgres is often a better option that betting on a new database entirely b) You can always use a GraphQL database along with Hasura + Postgres by bringing that in as a remote schema to Hasura! So you can use 2 databases simultaneously depending on your use-case.
3. DIY API: Here you're thinking about the choice of building your own API vs using Hasura. Hasura aims to give you an experience where you only think about your domain's data models and your domain's business logic (that could be deployed with, say, a serverless vendor) and not really the build/setup/deploy/operate/optimize lifecycle of an API server. I linked to this post above, but this blogpost might help in understanding how Hasura works: https://hasura.io/blog/how-hasura-works/

Question: Do you have any tips on handling authorization in a mid to large app in hasura? I have found that it can get quite confusing setting individual permisions for every field and worry about the security implication of "missing something" – roboticsound

This has indeed been raised in the past when the app gets complex with lots of permissions. The Hasura Console currently has a Permissions Summary view to give an overall picture of what permissions have been configured. Another way to think about security is to use the Allow Lists feature to specifically allow only a list of GraphQL operations to avoid exposing everything on the schema. But we are working on improving the UX around managing permissions in bulk so that you can apply them in bulk.

Question: I'm a noob when it comes to scaling/provisioning, especially when I need to interpret "20 GB data pass-through". Could you tell me what kind of project are supported by the standard cloud offering of Hasura? By kind, I mean the size of the project, the number of users using it, etc. Thank you for your input 🙏 – binajmen

The standard cloud plan is a pay as you go plan that auto-scales as your app scales. This means apps of any size are good to be hosted with High availability and auto-scaling. The data pass through is dependent on your API usage and response sizes. If you are caching your queries, then that would help in reducing the data pass through usage.

Question: what are your thoughts on postgraphile, and do you have any plans to allow [self-hosted] extensibility ala postgraphile's makeExtendSchemaPlugin to allow foreign data sources? – (d,f,g)=> {}

This might not be a direct answer to your question since I'm not very familiar with makeExtendSchemaPlugin, but on the theme of allowing foreign data sources and making that easy: We're working on something very interesting (currently named GDWs - GraphQL Data Wrappers, inspired by Postgres's FDW Foreign Data Wrappers ofcourse) that will allow people at Hasura, data-source vendors, and the broader OSS community to build Postgres FDW like extensions to Hasura in their favourite programming language and get the power of the Hasura GraphQL API!

We haven't talked about this anywhere yet 🤐, so you heard it here first and more news coming soon! 🙂

Question: If a friend would ask you about which Postgres DBaaS to choose, what would be your answer? 😇 – binajmen

If they are testing it out and hacking around, I'd say go with the built in Heroku integration. If they are wanting to kick off a serious project, I'd suggest Aiven or Fly.io - if they have investors who might get mad, I'd suggest having a look at an AWS solution. 😄 But Aiven and fly.io are my hipster picks for the moment. I've also been happy with raleway.