GraphQL + PostgreSQL: Need an ORM or just query builder?

Viewed 5764

We are about to start a big project, with several tables and relationships, we have to expose an API to consult the data. GraphQL seems like a great idea and we want to use it with PostgreSQL, my main question is whether we should use an ORM (like wetland) or just a query builder/helper (like knex). What do you think?

4 Answers

ORM vs Query builder

I would recommend using a query builder and not an ORM because with GraphQL it's easy for clients to query for nested information. The effort spent in optimising the ORM portion of your code will not be required if you were using a query builder based approach from the get go.

massive.js is probably an even better fit that knex for this kind of use case.

  • ORM pros: Migration tooling, easy to write code
  • ORM cons: Painful when optimising for nested queries, custom SQL
  • Query builder pros: Easy to map to efficient SQL queries
  • Query builder cons: No "objects" modelling that might make writing code easier

Instant GraphQL on Postgres

We also recently open-sourced our GraphQL engine which gives you instant GraphQL on a Postgres database as-is. The GraphQL endpoint is safe to be queried from apps directly because of an access control layer. This access control layer can integrate with any auth system (auth0, custom, forgerock etc.).

It is also performance optimised for making real-life nested queries fetching non-trivial amounts of data because we compile GraphQL queries to a single SQL query (instead of resolving them) which results in you being able to get a throughput of over a 1000 req/s at around 50-60MB of memory usage.

Hasura comes with optional rails-inspired migration tooling and an admin UI as well in case you don't have an existing migration system.

Related