Hacker News Reader

Comment by MadWombat | Hacker News Reader

One thing that bothers me about systems like this is the underlying assumption that database architecture always reflects the presentation. But what if ti doesn't? I am looking at the Hasura docs and all it really says is "we will generate everything for you based on your database schema and here is the way we do it". But what if I don't want some tables to be exposed? What if I want to expose custom queries instead of tables?

I feel that products like Hasura and postgrest would be a lot more useful if there was a way for me to specify a list of data sources on one side and get a fully formed GraphQL or REST service on the other side rather than going "I know what you need better than you" route.

View on HN

Data-driven architectures are very relevant, in particular in a corporate / business environment.

I found all the answers in the docs.

A SQL Schema can carry a custom query, it's called a view.

A SQL Schema can carry a custom algorithm, it's called a function or a generated column.

You can always deactivate permissions on a table to not expose it, my bet is that your backoffice will need to though.

On top of that, Hasura supports custom resolvers (code driven endpoints).

Finally you can stitch 2 GraphQL schemas together. It doesn't have to be one size fits all. So even if only 50% of your app can fit in the model of Hasura, you can always mix and match. It's still 50% that will be up and running in minutes.

> A SQL Schema can carry a custom query, it's called a view.

This is not feasible. I might not have enough access to create views. I might not have access to create functions. I cannot deactivate permissions if I only have a single access account and other systems use it already. You cannot assume that I have full control of the database or that I can easily make changes to the schema.

But this is not all. I am working on a web backend project on daily basis. I would love to offload some basic CRUD operations to something like postgrest or implement GraphQL with something like Hasura, but I need a way to a) define table and field name mappings b) define what tables are accessible b) define what columns are visible c) define what nested relationships are allowed d) define actions that need to happen on update/insert/delete operations (i.e. push a message into a queue every time a record is deleted from table T) If I could do all of this, I could implement about 50% of my web service and it would be useful.

Of course, if you don't have that access, it becomes harder and less suitable. BUT: If you have that ability, it is quite good. I think we are going into a SQL renaissance, especially if frameworks like this article is about will succeed in overcoming the classical ORM impedance mismatch

Please read the docs. All your fears are addressed in the doc. The permissions are managed on the Hasura side.

Concerning the lack of sufficient privileges to create a view, you can always either ask for permissions, or create a second databse with FDW. Apparently reading your second paragraph you are allowed to create tables, so it sounds like you'll also have enough privileges to create views.

I don't understand your point on your second paragraph. You can do all of that in Hasura, it's in the first tutorial, but also the doc. Please note we are talking GraphQL so there is no CRUD. It is a query + mutation model. More flexible and powerful than CRUD.

I think the philosophy behind this is that you're supposed to end up doing extensive presentation work in the DB itself through generated columns, views, access control, functions, etc.

It requires you to learn more arcane technologies (postgres functions are a bit less beginner-friendly than, say, ruby on rails) but these are also great technologies to know.

My guess is that a production hasura/graphile/prisma app would end up having a large number of custom resolvers by the time it's seen a few years of heavy production development as well, and that the built-in gql queries would serve more as scaffolding for prototypes, but I've never made it that far myself.

> I feel that products like Hasura and postgrest would be a lot more useful if there was a way for me to specify a list of data sources on one side and get a fully formed GraphQL or REST service on the other side rather than going "I know what you need better than you" route.

Hasura internally has a metadata engine that does exactly this. You explicitly specify what tables/views/functions you want to expose and how you want to expose them. You can use Hasura authz to further constrain what data is accessed/returned while a query runs. In its default configuration when you start Hasura against your Postgres, Hasura exposes nothing.

I will need to take a closer look. If you are right, this might be more useful than I thought at a casual glance.

Reply on news.ycombinator.com