Skip to content

PostgREST instead of hasura #31

@yonil7

Description

@yonil7

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions