-
Notifications
You must be signed in to change notification settings - Fork 3
Description
I'll be happy to get your opinion on basing the data-api on PostgREST instead of hasura.
This post list some of the advantages: https://www.freecodecamp.org/news/stop-calling-postgrest-magic-8f3e1d5e5dd1/
- It has a well thought out query language (similar to SQL)
- full text search
- renaming columns
- extracting nested fields from a json column (json_col->phones->0->number)
- computed columns
- sorting with null handling
- limits and pagination
- resource embedding: query columns from related tables (foreign keys) in a single API call (e.g. GET /films?select=title,directors(id,last_name))
- response formats: csv, json, openapi, plain text, binary stream
- can automatically expose OpenAPI (similar to exposing schema by GraphQL)
- schema isolation: expose views and stored procedures (as abstraction layer) instead of exposing the real tables
I understand the flexibility offered by GraphQL but it might be less suitable for querying tabular data (e.g. efficiently return 1M rows as CSV)
This is partly because it uses a graph data model - while we can model a table as a graph, the framework is lacking basic tabular concepts "understanding" such as "rows" which might make it suboptimal for this kind of data
Also, I don't like the fact that with GraphQL, we can't use a simple browser for running a query (e.g. when collaborating with non-professional, I like to be able to send a query as a URL that will download a csv with the relevant data when opened in the browser)
Another relevant project - https://github.com/subzerocloud/postgrest-starter-kit, makes PostgREST even more powerful.