Skip to content
Back to blog
GraphQLHasuraPostgreSQLBackend

Hasura: Getting a Full GraphQL API Without Writing Resolvers

2 min read

After years of writing REST endpoints and GraphQL resolvers by hand, Hasura gives me the whole API from a Postgres schema. Here is why I made the switch.

Every backend I built before 2024 involved writing resolvers by hand. Define the schema, write the query, map the fields, handle the errors, add the auth check. For a table with 10 columns, that is 200 lines of boilerplate before you have written any real logic.

Hasura generates the entire GraphQL API from your Postgres schema. Every table gets queries, mutations, and subscriptions. Relationships become nested fields. Row-level security is defined in YAML metadata, not in application code. The API is live the moment you track a table.

The permission system is what sold me. Each Hasura role gets a set of row and column permissions defined declaratively. A user with role "site-owner" can only read rows where site_id matches their x-hasura-site-id claim. This is enforced at the database layer, not in middleware. You cannot forget to add an auth check because the check is part of the schema.

The biggest surprise was performance. Hasura compiles GraphQL queries into a single SQL statement. No N+1 problems, no round trips, no dataloader patterns. A query that fetches a site with its pages, posts, skills, and work entries resolves in one database call.

When I built nSelf CLI, Hasura was the obvious choice for the GraphQL layer. It runs as a Docker container alongside PostgreSQL and exposes a production-ready API with zero application code. The time I would have spent writing resolvers goes into building actual features instead.

Related Posts