Hasura FAQ: What are the best practices? (Part 1)

Have you been wondering about best practices with Hasura? Here’s a quick rundown of some of our recent FAQ’s.

Actions are the new hotness for business logic. Check out:

• Docs
• Demo

Other approaches for custom business logic:

• Remote schemas & remote joins: When you have an existing or external GraphQL server.
• Event triggers: When your logic only needs to run after a data change event in the database.
• Scheduled triggers: When your logic runs on an interval (cron) or a scheduled time in the future.
• Postgres functions: When your logic is data-intensive and fastest/easiest when implemented as a Postgres function.

Our blog post on all of the above

Sounds like you’re looking for a fluent GraphQL client. We wrote about this recently: Fluent GraphQL clients: how to write queries like a boss

These clients give you the ability to write queries as objects instead of strings. Some of them also integrate with TypeScript and eliminate duplicate data definitions.

Hasura migrations make managing environments easy. Check out:

• Docs
• Demo: Migrating a GraphQL + Postgres app from Staging to Production

Actions allow you to run business logic before executing a mutation. With an action, you can call an HTTP webhook (a REST endpoint or a serverless function) that talks to your auth provider, sign up the user with the provider, and save the user to your database afterwards. And here’s the kicker: Hasura provides a codegen that generates the handler code for you.

Also, check out this guide on creating a GraphQL API for Notion with Hasura Actions.

Update your Hasura GraphQL engine to the latest stable version.

That’s it for now. Do you have any burning questions regarding best practices with Hasura? Ask us in the comments! 👇👇👇