vsurabhi

(Vamshi from Hasura)

We've been working on SQL server native support and we're happy to announce support for read-only GraphQL cases with new or existing SQL Servers.

Next up is adding support for stored procedures, mutations, Hasura event triggers [1] and more!

[1]: https://hasura.io/docs/latest/graphql/core/event-triggers/in...

This and a recent feature addition to neovim (passing lua closures to vimscript functions [1]) should make a good substitute for elisp to configure neovim.

[1] https://github.com/neovim/neovim/pull/12507

I've been using osquery (https://github.com/osquery/osquery) for a while. It is neat and I can appreciate the idea of 'exposing OS interfaces as databases'.

If you are using Postgres as your database you can use Hasura to add GraphQL APIs on top of all the tables. Hasura can be exposed to the fronted applications with declarative permissions. You can add a reverse proxy if you want to. Hasura scales horizontally but you will have to manage Postgres on your own or use a hosted Postgres service like RDS.

> .. caching .. This is related to GraphQL in general. The support for caching is nowhere close to what is possible with RESTful APIs but it should eventually get there.

While Hasura is a 'BaaS' (in the sense that it can be directly exposed to frontend applications), it absolutely does not come with the limitations that you have mentioned. Hasura is not an 'either or' solution like Graphcool or Parse or AppSync. Hasura is designed to scale with the complex requirements of a project over time and to get out of the developer's way when they need more power.

One of the main reasons why this is possible with Hasura and not possible with say Graphcool is the abstraction which Hasura provides. Hasura is not a black box which lets you do CRUD operations. It is a tool that adds powerful GraphQL APIs on top of Postgres, i.e, it works with any Postgres database, existing or new, no restrictions whatsoever. This means you are free to write your own code (and encouraged to) which speaks to Postgres directly with your favorite ORM and expose these APIs with "schema stitching" alongside Hasura.

Hasura therefore lessens the work of a GraphQL backend developer: use Hasura's GraphQL APIs when they fit your bill and write your own custom logic when needed as you would have done without Hasura.

In fact Hasura is a superset of Prisma when it comes to Postgres, you can also use Hasura as an ORM if you want to.

Disclosure: I work at Hasura on graphql-engine

> .. completely flew over me

Thanks for the feedback. We thought that the 'BaaS' part would convey it.

> .. small datamodel to a very complete GraphQL types ..

Given any GraphQL server, you can generate the types/functions (using introspection) to access the GraphQL server in a typesafe/idiomatic way for a language. A project which does this: https://github.com/dotansimha/graphql-code-generator.

That's pretty much what we are doing at Hasura, expose Postgres to the client directly with a powerful enough query language on top of GraphQL so that developers can get away with writing as little business logic as possible.

The biggest challenge is access control which we have modeled based on Postgres's RLS but for application users and roles.

Prisma is used as an ORM for your database, so you would still need to write your own graphql server which sits in front of Prisma.

Hasura is meant to be exposed to the clients directly with declarative access control rules. When you have complex business logic you would write the logic yourselves and expose it alongside Hasura.

Disclosure: I work at Hasura on graphql-engine

I think you should be able to use it alongside SQLAlchemy if you manage your schema through Prisma. Someone from Prisma team should be able to give you a more thorough answer.

Very similar projects ! The emphasis of Hasura is to make it seamless to work with existing databases.

The primary difference is how authorization is handled. In Postgraphile, you map your application roles to Postgres users and define policies using Postgres's RLS. With Hasura, you define rules on roles (similar to Postgres's RLS) but it integrates into your existing auth system using webhooks.

We do not batch queries. We take a slightly different approach. We convert the GraphQL query AST into a single SQL query (no matter how nested the GraphQL query is).

> What I'm not seeing is how do you ..

You can write fairly complex rules with the access control layer ! The first two conditions are possible (except for the project is only visible on Mondays).

  allow select on rows which satisfy this property: 
  { "project_type" : { "_eq" : "whatever" } }

  allow update on rows which satisfy this property: 
  { "closed_data" : { "_is_null" : true } }

The idea is simple, we provide a boolean expression based access control layer which can use variables from headers. When you can't specify it using the access control layer, you can write this in your own graphql layer and schema stitch with hasura. So you only have to write what is not possible with the access control layer.

> The other point I don't see is how do you ...

You can use the tooling around Postgres ! You can create an `ON INSERT` trigger on the table and listen to these events.

We're launching something very cool in the subscriptions/event-source to solve these kinds of problems. We also have 2 nice projects that work independent of the graphql-engine to help with change subscription on postgres (skor[1], pgdeltastream[2])

[1] https://github.com/hasura/skor [2] https://github.com/hasura/pgdeltastream

Hi, I'm one of the core contributors to the project.

Hasura and Prisma have very different approaches and end-goals at the moment.

TL;DR: Very simply put, Hasura is postgres first and adds an access-control layer to make it possible to query from the front end directly.

The longer version:

Prisma is intended to be a GraphQL ORM to Postgres (and several other databases with a common API) whereas Hasura is more database first and intended to let you leverage Postgres features over GraphQL.

Hasura comes with and lets you use any postgres migration system and then gives you GraphQL on top of it. This is what allows Hasura to give you GraphQL over any existing Postgres database and application even.

Hasura also comes with an optional access-control layer that makes it feasible to be used by frontend clients directly. This access control is inspired from postgres's RLS but does not depend on or use postgres RLS and can be coupled with application logic/auth.

That's great news ! So the trigger can use json_agg to compose the notification with all the modified rows. We'll document it (https://github.com/hasura/skor/issues/8).

Currently there is no support for rate limiting or retries of webhook calls. I've opened an issue (https://github.com/hasura/skor/issues/7)

100 webhook calls as the trigger is executed whenever a row is modified.

Postgres's per statement triggers don't let you capture the rows that are modified and skor doesn't do any sort of batching currently.

Yes. That is correct. It fails with large rows. I'll add this to the limitations. The trigger currently sends the entire row but it can be modified to send just the unique identifier for a row. I'll add the documentation to do this. Tracking this here: https://github.com/hasura/skor/issues/6

(I work at Hasura)