[andrewingram]

It’s arguably the least sophisticated of the major clients (Apollo, Urql, Relay), but they’ve done a great job with marketing and documentation. But I’ve personally never used it in a real project because Relay has always existed and I know how to use it.

[nonethewiser]

And for the server? What do you use instead of Apollo?

[andrewingram]

Depends on language, I've build GraphQL servers in a few, though mostly JavaScript and Python. For Python I used to use Graphene, these days I use Strawberry.

For JavaScript, I originally used graphql-js and express-graphql, as these were the original libraries and I was a literal day 1 adopter. All the libraries are essentially just wrappers around graphql-js, so it's still viable to use directly. But for schema-building I now use Pothos (https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix).

[dventimihasura]

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

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

https://hasura.io/

[andrewingram]

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.

[dventimihasura]

Can you give reasons for why you believe that?

[andrewingram]

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.

[dventimihasura]

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?