I know this may not be exactly on topic, but do you know when version 2 will be released? My team has been waiting on a single feature from that release for what seems like months (slack in jwt verification time, right now the clocks on our hasura and keycloak servers are off and it is creating issues).
Hey! We released 2.0-beta.2 this week and we're planning on releasing 2.0-stable on Mon/Tue.
Sorry, I know it took a while, but we had to make sure we could make the upgrade path non-breaking given it was a massive release and this took longer than we expected!
Please do feel free to reach out if you need any help with the upgrade :)
I don't use it directly, our systems engineers maintain and configure it. They had some trouble getting clustering to work for a while, but not sure if that was really the fault of keycloak.
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.
I don't see it mentioned but there is a neovim plugin called conjure [1] that is written in fennel. This is a general purpose REPL client that works for Clojure (I use it daily for Clojure and ClojureScript) but also for fennel itself. So you can have a really nice neovim plugin dev experience using this tool. Conjure works with fennel out of the box, but if you want to go deeper you may be interested in another plugin called aniseed [2] which provides interesting facilities for the fennel language and that is used internally by conjure.
Disclaimer: I am not the author of those tools, just a random Clojure dev.
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'.
osquery is cool. But, as far as I know, it doesn't expose the filesystem as a database, it is closer to /proc-as-a-database. (osquery can monitor specific files, in particular security-sensitive files, and expose events related to those files in SQL tables; but I don't think that facility is scalable from certain specific files to the entire filesystem.)
Indeed it isn't, in order to make file-level querying performant at all, you really need support for that at the filesystem level. Which is exactly what BFS, the BeOS filesystem had, and of course Haiku reimplements it: https://www.haiku-os.org/docs/userguide/en/queries.html
As that page describes, the "query" command (or its equivalent GUI) can be used to write filesystem queries, e.g.:
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.
Here is my use case.
I want to make a SPA. So i need to use a GraphQL client library like relay which again directly talks with Hasura. I am not sure where does the reverse proxy fits in.
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.
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.
FWIW I appreciate the balance hasura is going for re: RLS. I balked at the interfaces I’d have to maintain to get strict pg-user per profile row access. It is nice to have a ramp.
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.
Gotcha! It might just be my inexperience but that completely flew over me from your landing page. I can see how the auth bit implies it, but that sounds pretty cool and isn't really clear IMO!
Do you have something like Prisma's conversion from a very small datamodel to a very complete GraphQL types + functions file going on in the middle then?
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.
Is there any sample app / quick start template of a full stack CRUD app (notes, todos etc) with user registration, signin? Not too clear on authn/authz seems to need to go down to Postgres level for such controls.
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.
Another salient difference (and, for me, a deal-breaker): PostGraphile exposes user-defined functions in the GraphQL API, making it possible to define application logic and build a complete service without recourse to any other server-side technology.
Would you mind expanding on this a bit? It seems HGE makes a call to a webhook for every GraphQL query/mutation [1]? This sounds rather expensive to me. Thanks!
We're adding support for JWT soon too which should prevent this overhead for applications that support JWT. But basically the idea here is to be equivalent to session cache hit.
Another deployment pattern is to make everything go through an API gateway which would usually do the auth resolution for all microservices, and thus can set the dynamic variables required for access control for HGE directly too. In this case, auth-webhook is disabled.
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).
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])
> u can write fairly complex rules with the access control layer
Oh, I see. As a suggestion then, many business rules are not tied to roles. You may want to look into some "always enforced rules" or something like that, to avoid having to repeat these rules for each role (and the maintenance nightmare this entails).
> your own graphql layer and schema stitch with hasura
Again, I'm not versed in GraphQL in general, so this is from my ignorance. Maybe you could provide some example/tutorial on "stitching your own GraphQL apis with hasura" (your other examples, posts and tutorials are awesome btw!).
> You can use the tooling around Postgres
Fair enough. I've always found a bit hard to properly manage and test these native features (much harder than managing/testing pure code), but it is a sound solution nonetheless. Maybe you want to hint to these other projects somewhere in hasura's docs (I've checked them and couldn't find it, but maybe I'm just blind/didn't look hard enough).
Again, awesome project and good answers. I can't stop going through possible pet-projects to try this out soon! :)
For "access control layer" to work in the general case we need to be able to code it in a real programming language, no? Or are you going for something one-size-fits-many like Sharepoint?
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...