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.
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.
> 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.
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.
