Hacker News Reader

Hacker News

Comment by dventimihasura | Hacker News Reader

Parent Full thread

dventimihasura

https://supabase.com/blog/pg-graphql

https://www.graphile.org/postgraphile/

https://hasura.io/

View on HN

Personally I wouldn’t advocate for these as I don’t believe it’s a good idea to automatically generate a GraphQL schema based on your database (I haven’t worked on anything in years where this would’ve been a good idea). But YMMV as always.

Can you give reasons for why you believe that?

In a world where you have multiple clients, you want to minimise duplicate work of derived state. Unless your UI-level data model is 1-1 with your persistence layer (rare, in my experience), there’ll need to be a transformation somewhere, and since your GraphQL server provides a common interface for UI clients, this transformation should happen at or below the GraphQL layer.

I'm trying to follow you. Are you saying that different UIs should (or may) have different data models, which themselves are different from but still derived from and related to the persisted data model?

Say you have a web app, an iOS app and an android app. And let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data in the database. It means somewhere between the database and the UI template you’re going to be transforming from one model to another. What you don’t want to do is have the equivalent transformation implemented 3 times — once per app; instead you want to do this transform at or below the common interface that they call operate against, ie the GraphQL server.

In my experience it’s very uncommon for anything other than simple prototypes to not have at least some divergence between the UI model and the persistence model.

First, let's take these two propositions.

> Say you have a web app, an iOS app and an android app

and

> let’s say the model of the data that makes sense for the purposes being the UI for these apps is different from the model that’s used to persist data

Question: If we stipulate that the UI models are different from the persistent model, are the UI models are different from each other or are they they same? What I mean is this. Do the web app, iOS app, and android app models differ from each other? This is important for my reasoning that follows.

Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop.

The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.

Ok. Thanks for that clarification.

In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.

Can be, sure. But SQL, whilst very capable, isn’t the language I’d reach for in order to define my entire business logic layer. Sometimes these transforms are fairly involved and pull in things from multiple data sources and APIs, yes these can be done with advanced SQL wrangling, but at some point you’re just using the wrong tool for the job.

Reply on news.ycombinator.com