5 ms·
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 person
by andrewingram 4y ago
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 4y agoAnd for the server? What do you use instead of Apollo?
- andrewingram 4y agoDepends 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/ https://pothos-graphql.dev/), I'd probably use graphql-helix as the http layer (https://github.com/contra/graphql-helix https://github.com/contra/graphql-helix).
- dventimihasura 4y agohttps://supabase.com/blog/pg-graphql https://supabase.com/blog/pg-graphql https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ https://hasura.io/ https://hasura.io/
- andrewingram 4y agoPersonally 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 4y agoCan you give reasons for why you believe that?
- andrewingram 4y agoIn 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 4y agoI'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?
- andrewingram 4y agoSay 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.
- dventimihasura 4y agoFirst, let's take these two propositions. > 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.