News for hackers. Stuff that matters.
Re:Tuql: Automatically create a GraphQL server from a SQLite... by ricardobeat on Wednesday April 26, 2023 @07:37PM (#35721394)
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.

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. 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 how would you stop it from being populated with other potentially-wrong schemas and finding yourself back at square one?

Re:Tuql: Automatically create a GraphQL server from a SQLite... by no_wizard on Wednesday April 26, 2023 @07:46PM (#35721454)
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