[davidmccabe]

GraphQL is really intended to model UI concepts rather than directly exposing your database schema.

First of all, your GraphQL schema is basically append-only due to older clients that may remain in the wild. So you don't want to expose implementation details that may change.

Second, you want to write client code that handles mutations. This is easier if the data the client receives is organized in a UI-centric way. I'll give you a simple example that came up at work recently: a single conceptual category (a "user account") that, due to implementation details, was spread across two different tables with different columns. Because the GraphQL schema in this case mapped each table to its own GraphQL type, somebody was then able to write client code that only handled one type and not the other, causing an inconsistent UI.

I would suggest thinking carefully about your GraphQL schema, treating it as an API, and not auto-generating it. Of course, you want it to be convenient to construct, just not fully automatic and thoughtless.

[ricardobeat]

I imagine a lot of people don't share this particular opinion. The problem GraphQL was created to solve is precisely the ability to compose ad-hoc queries to feed into UI, without being tied to a particular data model or mapping. It allows applications to change at a faster pace without requiring centralized API modifications.

If you create those UI-centric models when exposing data through your GraphQL schemas, you just moved the modelling work elsewhere but haven't actually facilitated anything, and it's still centralized. At this point you're better off embracing the 'BFF' architecture and skipping GraphQL altogether.

There may be a useful middle ground (for example, ensuring a single User type), but it's a slippery slope to stand on.

[no_wizard]

I think if you look at it from the otherside it makes more sense.

A problem that is common is that we send these JSON blobs over the wire that aren't purpose fit. So, with GraphQL, we can construct a query graph that makes the JSON blobs slimmer and more purpose fit, by constructing the queries to return the data we desire for some particular business reasons we need to represent in the UI, for instance.

I got the argument with mutations need to match things more closely, but I'd argue you can cross compose mutations w/ resolvers too.

I think this is what they're getting at. Just throwing the database schema over the wall via GraphQL isn't that much better than REST, and takes zero advantage of abilty to use revolvers to construct purpose built queries

[no_wizard]

This is what I constantly tell people. Use GraphQL to efficiently create permutations of access so the data is shaped for the client more or less exactly how they need it. To that end, I often recommend that at least one UI developer is involved in approving schema changes and regularly dogfoods the GQL setup before its deployed.

I have been met with a lot of resistance around this notion for some reason.

To be honest, I fought the same argument with OpenAPI (Swagger) too.

API developers seemingly just want to chuck their schema over the wall and walk away

[mst]

I think part of this is that when an API developer tries to write frontend code, they'll naturally use the underlying schema as their frontend domain model because they're already thinking in those terms.

I definitely suffer from that problem when trying to work out what a good API for frontend would be, and frontend people often have their own blind spots which makes working together to find something actually good a tricky process.

Then again, getting REST/GraphSQL/API-of-choice designs 'actually good' is hardly a trivial problem at the best of times, so how much of this is developer biases and how much inherent difficulty isn't something I'd be confident trying to estimate.

[camgunz]

Yeah this dynamic definitely exists. I think this is because there's a big mismatch between what frontend wants ("we'd prefer a single, super fast endpoint with no params") and what backend wants ("we automatically exposed our database tables complete with RBAC, query away"). Backend engineering has more or less become all implementing this mapping layer, whether it's with graphql resolvers, db views, or whatever, but the work to be done is like 90% here.

[TheNewsIsHere]

I’ve been kicking around a project idea for years that would be a niche fit for these considerations. It’s effectively an extremely niche reference corpus of very field-specific data, effectively represented by JSON documents and having a few relationships that don’t require transactions. It wouldn’t be editable by clients at all. Every client would be nothing more than a consumer, and the database would be versioned and only edited by the maintainer.

That is certainly not a common use of web based APIs, to have an application that is read only every client, but the reason I came to this thread was because I’ve considered SQLite for this idea in the past.

[anthlax]

Could you explain that “two tables” issue again? I’m trying to think of a way that DB constraints (I’m using Postgres, fwiw) couldn’t handle denormalization, but imo there’s a constraint for everything. Force a 1:1 relationship, or add a check constraint so you literally cannot denormalize.