JSJ 401: Hasura with Tanmai Gopal

JavaScript Jabber - Un podcast de Charles M Wood - Les mardis

Catégories:

Tanmai is one of the founders at Hasura. Hasura gives you instant graphQL APIs on top of a Postgres database. The eventual idea is to make data access secure and easy. Tanmai explains the challenges of doing this in the cloud. He talks about some of the difficulties with the tooling around using GraphQL and its bias towards working well with a monolith. Since GraphQL is basically a shared type system that describes your API, that means all your types need to be in the same code base. This is at odds with the folks who want to do microservices and serverless functions, because since their API is split across multiple services they have different types, and forcing these types to work together defeats the purpose of using microservices. Also, storing state across requests doesn’t work well with serverless and cloud native stuff. In short, learning to live without state is one of the general challenges with going serverless.

This is where Hasura comes into play, and Tanmai explains how it works. Hasura is metadata driven, and each instance of the server can leverage multiple calls and exhibit a high amount of concurrency. It’s designed to be a little more CPU bound than memory bound, which means that configuring auto scaling on it is very easy and allows you to utilize the elasticity of cloud native applications. Tanmai clarifies his usage of the word ‘cloud native’, by which he means microservices. He explains that when you have a metadata based engine, this metadata has a language that allows you to bring to bring in types from multiple upstream microservices, and create a coherent graphQL API on top of that. Hasura is a middle man between the microservices and the consumer that converts multiple types into a single coherent graphQL API.

Next, Tanmai explains how Hasura handles data fetching and a high volume of requests. They also invented PostgresQL, RLS-like semantics within Hasura. He explains the process for merging your microservices into a single graphQL interface. Back on data fetching, Tanmai explains that when the product is an app, preventing an overabundance of queries becomes easier because during one of the staging processes that they have, they extract all of the queries that the app is actually making, and in the production version it only allows the queries that it has seen before. Hasura is focused on both the public interface and private use cases, though private is slightly better supported.

Tanmai talks about the customizations available with Hasura. Hasura supports two layers. One is an aliasing layer that lets you rename tables, columns, etc as exposed by PostgresQL. The other is a computer column, so that you can add computer columns so you can extend the type that you get from a data model, and then you can point that to something that you derive.

The panelist discusses the common conception of why it is a bad idea to expose the data models to the frontend folks directly. They discuss the trend of ‘dumbing down’ available tooling to appeal to junior developers, at the cost of making the backend more complicated. They talk about some of the issues that come from this, and the importance of tooling to solve this concern.

Finally, Tanmai talks about the reasons to use Hasura over other products. There are 2 technologies that help with integrating arbitrary data sources. First is authorization grammar, their version of RLS that can extend to any system of types and relationships, The second is the data wrapper, part of the compiler that compiles from the graphQL metadata AST to the actual SQL AST. That is a generic interface, so anyone can come in and plug in a Haskell module that has that interface and implement a backend compiler for a native query language. This allows us to plug in other sources and stitch microservices together. The show concludes with Tanmai talking about their choice to use Haskell to make Hasura.