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.
What's the best practice for managing business logic?
Actions are the new hotness for business logic. Check out:
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.
Is there a way to prevent GraphQL queries from becoming a pile of strings?
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.
What's the recommended practice for dev/staging environments and persisted data?
Hasura migrations make managing environments easy. Check out:
I want to have my own custom signup flow. What’s the best way to achieve this?
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.
I don't see Actions on my console. How do I go about enabling it?
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! 👇👇👇