I should’ve misphrased, I meant the database schema. Of course frontend needs to display data, but it should not know anything about how the data is organized in the persistence layer. But what I know of GQL so far is that: frontend needs to assemble queries in exact awareness of the database schema.
In my opinion, it may decouple the frontend from the backend by skipping it, and couples directly to the schema instead, which I can’t see as an optimal architectural decision (maybe I’m oldschool :).
No the graphql schema is completely independent of the storage layout. This is largely the point of it. There are some people who are using magical make-an-api-from-my-database tools, and this coupling concern seems to be a common complaint. But it’s a problem with how you’re using the tool (you want a schema of views) and not with graphql.
Thanks for shining light to it! I had a suspicion that I saw the wrong examples (and, you may guessed, I haven’t used it in production yet). But you comment is clarifying, I’ll try to get my head around this new (to me) idea.
It’s hard for me to believe that using GraphQL, which couples the frontend to the data, mentioned as a solution for decoupling.
No it doesn’t. It decouples the backend from the frontend. The “make me an endpoint for each feature” thing is very real.
What would be a frontend that isn’t coupled to the data it displays?
I should’ve misphrased, I meant the database schema. Of course frontend needs to display data, but it should not know anything about how the data is organized in the persistence layer. But what I know of GQL so far is that: frontend needs to assemble queries in exact awareness of the database schema.
In my opinion, it may decouple the frontend from the backend by skipping it, and couples directly to the schema instead, which I can’t see as an optimal architectural decision (maybe I’m oldschool :).
No the graphql schema is completely independent of the storage layout. This is largely the point of it. There are some people who are using magical make-an-api-from-my-database tools, and this coupling concern seems to be a common complaint. But it’s a problem with how you’re using the tool (you want a schema of views) and not with graphql.
Thanks for shining light to it! I had a suspicion that I saw the wrong examples (and, you may guessed, I haven’t used it in production yet). But you comment is clarifying, I’ll try to get my head around this new (to me) idea.