Can you do a full write-up about this tool?

Looks really interesting to easily layer a graphQL API on top of a Rails app with a few serverless functions...

A "full write up" seems a bit intimidating... :)

I'll expand a bit on my previous comment.

So the idea is that Hasura is a stateless layer on top of Postgres that generates all the necessary GraphQL schema/queries/mutations/real time subscriptions for doing CRUD based on the Postgres schema. If you change the tables (either via the Hasura admin or some migration system) it all adapts automatically as you'd expect. It can use a remote Postgres DB, you don't need to run the API and DB in the same machine.

Performance is fantastic. Hasura is very efficient in terms of speed and memory consumption. Even with a free Heroku dyno you should get thousands of reqs/s.

On top of direct data from tables you can also read Postgres views. Essentially you can read a custom SQL query from GraphQL.

Hasura can also integrate external GraphQL schemas via a mechanism it calls "stitching". The idea is that you can point remote GraphQL schemas to Hasura (on top of the current one from Postgres) and it will serve as a gateway of sorts between all your GraphQL clients and servers.

Hasura does not include authentication, but it's very easy to integrate with your current system or with services like Auth0 via JWT.

Hasura also includes a powerful fine grained role-based authorization system.

Whenever anything happens you can configure Hasura to call a URL (webhook) to do something. Maybe a REST endpoint or a cloud function. This is usually the way to integrate server side logic.

The only problem we've found is integrating Hasura with our current authorization system. Our users have multiple roles and we have no way of deciding which is the current role. Hasura requires a single role to be passed to its authorization system on the request headers. This is something that is being worked on AFAIK.

Their youtube channel has lots of little videos showcasing all the functionality.

https://www.youtube.com/channel/UCZo1ciR8pZvdD3Wxp9aSNhQ/vid...

I've created a few projects using the Node/Express ecosystem and have so far loved it. I'm starting to branch out and learn Go now. Can you discuss/compare your experience working in both ecosystems?

We switched from a small Node Hapi monolith to Go at the end of 2017. The main reason to switch was that we wanted to get types to get more explicit code. We considered a number of options (TypeScript, .NET Core, Dart, etc) and ended up picking Go because it's a nice simple language and the performance is great over Node.

We reduced memory usage by 80% over Node. We never had a performance bottleneck with Node either but it feels nice to be running on the smallest Heroku dyno and knowing you won't need much more for at least a couple of years.

As for the developer experience we vastly prefer Go over JavaScript. It's more tedious at times but there is no more ambiguity. We love that we barely need any dependencies. Moving from JS to Go was extremely easy as all devs in our team are polyglots and Go is pretty simple. I don't know how easy it would be for a JS only dev, but I imagine it wouldn't be too hard.

When using NPM/Node/JavaScript it seems there are always hidden dangers, probably more in the front end than when doing backend Node. With Go there are no surprises, everything feels solid and predictable.

After about 2 years with Go we are still happy with the decision.

Thanks for the detailed response! I was definitely going to ask 'why not TypeScript?' if your issue was mainly types, but you beat me to it! I reached similar conclusions regarding the benefits you witnessed switching to GO; it's nice seeing them spelled out.