Hacker News Reader

Comment by tayo42 | Hacker News Reader

I have pretty limited experience with graphql. Why is apollos offering interesting to people? A hosted graphql proxy? You still need to write your own servers(but theres a ton of good libraries in multiple languages for this?)

Architecturally it seems to be adding a massive hop to requests made, but its not clear to me what the benefit is?

View on HN

I don't know about the company or how they make money with it (support?), but Apollo is pretty much the standard GraphQL client for frontends. It has pretty sophisticated cache and state management, type generation for typescript, etc.

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.

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

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).

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

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

https://hasura.io/

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.

Can you give reasons for why you believe that?

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.

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?

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 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.

First, 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.

Generally no, they’re not different. For example, the consumer Twitter apps; or when I worked there, Depop.

The situation may change if you also add internal tools to the mix, since they’re often operating on a superset of data that the consumer apps might have access to - though still not necessarily the same model as the persistence layer.

Ok. Thanks for that clarification.

In any case, your requirement can be satisfied by SQL views, which transform the persisted model (tables), and which are 'below' the GraphQL server.

Can be, sure. But SQL, whilst very capable, isn’t the language I’d reach for in order to define my entire business logic layer. Sometimes these transforms are fairly involved and pull in things from multiple data sources and APIs, yes these can be done with advanced SQL wrangling, but at some point you’re just using the wrong tool for the job.

What these companies offer (another one I am using is "The Guild") is mostly tooling and DEX. GraphQL is a specification. The implementation will depend on the tools/infra you'll use. That's what these guys offer.

In addition to the other comments, their APM platform is built specifically for graphql so it includes things like query performance on the field level. Existing tools don’t always play nicely since a graphql server is usually just one endpoint and doesn’t use normal status codes.

They also provide libraries for both the client and server so they can tell you what versions of your client are using specific data.

Managed schema evolution mostly. Essentially git branches for your schema, that you can't merge if it would break your clients.

Reply on news.ycombinator.com