Stack · Backend
GraphQL — one query per screen
EcosystemGraphQL
GraphQL is how I've fetched data on most client projects since 2019 — usually with Hasura serving the schema, sometimes with a hand-written resolver layer over an existing service.
Why I use it
Its clearest win is on mobile, where round trips are expensive and unreliable. A screen asks for exactly the fields it renders, in one request, and the schema is introspectable so the client types generate themselves. The cost is real though — resolver-level N+1 queries and unbounded nesting are easy to write and easy to miss until load arrives. For a small app with two endpoints, REST is still the honest answer.
What I've built with it
- Schema design for client apps, modelling around what screens need rather than mirroring database tables one-to-one
- Generated typed hooks from the schema, so a field rename surfaces as a compile error rather than an undefined at runtime
- Hasura permissions and row-level rules to keep authorization in the data layer instead of duplicated per client
- Cursor pagination and query depth limits on the endpoints that needed protecting
Alongside
Rest of the stack
Got a project that needs GraphQL?
Get in touch →