Hacker News Reader

Comment by jayd16 | Hacker News Reader

This is the strange thing about GraphQL, it shifts the work to someone else so you'll end up with people teams that benefit and teams that don't. You also need opt in from both the client and server.

I wish there was a client side library that implemented GraphQL as an abstraction over REST, GraphQL or other backend APIs. It would be nice to use some of the GraphQLs query/join features across several backend services without those services having to change. Imagine being able to merge a vendor API that can provide a tracking number with FedEx's API, for example.

View on HN

There’s actually nothing server specific about GraphQL. The specification makes no mention of transport layer, it’s simply a type system + query executor.

You can pretty easily (if you have experience with the GraphQL reference implementation in JavaScript) create a GraphQL layer that sits inside of the browser, with a schema created by the UI team, that executes calls to REST APIs to resolve the data.

You could think of it as an “ORM” for the browser, which seems cool, but I wouldn’t necessarily recommend this approach (though I have done it in the past) for two reasons:

1. The “graphql” library isn’t really optimized for size so it can add a bunch of overhead to your JavaScript bundles

2. One of the benefits of GraphQL is to combine multiple requests for related data into a single query to be sent from the browser. Yes, that makes the life of the backend developer harder as they try to optimize for performance, but it makes for less data/fewer requests over the wire to the client. If you stick GraphQL in the browser, you’ve now just moved your N+1 query across the internet.

If you really want to go down that road, Apollo offers a “plugin” to their GraphQL client that allows you to call multiple REST endpoints as if they were a single GraphQL endpoint (without embedding the actual “graphql” library in the browser): https://www.apollographql.com/docs/link/links/rest/

A better approach for what you’re looking for would be to schema stitching (which allows you to combine multiple GraphQL endpoints together and treat them as one. You can even combine that with your own schema definitions to mix in whatever backend sources you want; e.g. your vendor + FedEx REST APIs): https://www.graphql-tools.com/docs/stitch-combining-schemas

Or if you don’t want to do the work yourself, check out OneGraph, which uses schema-stitching to do exactly what you describe. It’s pretty cool: https://www.onegraph.com/

I don't think #2 is that big of a deal if all requests happen async, which they should with a client side ORM, and if you're using http2.

I think the bigger problem there is how those multiple REST calls map to your data stores. Very rarely will there be clean separation of data between endpoints, and the stateless nature of REST makes it harder to optimize each call -- meaning, there will almost certainly be redundant queries.

That said, with GraphQL, your front end dev may not realize they are executing the equivalent of many REST calls, which is another problem :) I wouldn't say it's harder to optimize if you look at the application as a whole, though.

If you cache enough, your frontend dev can call as many things as they want and it will still be more or less instant.

Some people, when confronted with a performance problem, think "I know, I'll use a cache." Now they have two problems.

(in other words: caching is complicated, and may make your systems very hard to understand & debug)

> There’s actually nothing server specific about GraphQL.

I just grokked this very recently when I was reading up on Gatsby and the fact that they use GraphQL. I was confused for a bit because Gatsby is SSG, until I realized they merely use GraphQL as a generic way to query any JSON data you might have laying around, similarly to how getStaticProps() is employed in NextJS

“ it shifts the work to someone else” I don’t think this is specific to graphQL. I’ve seen similar patterns with (to pick a recent example) shared front end component libraries. You make something more general at the expense of increasing complexity, if you have a team dedicated to that more complex proposition and enough consumers of that system you might well benefit at an org level. but if you don’t it’s easy to get caught up supporting that complexity at greater cost in time and effort than a less general solution would require. It’s a tricky call

Gatsby does this, and I’ve built a POC that did the same thing to try to get my workplace to adopt it. I shelved it after a demo as I didn’t love the idea of maintaining a bespoke API solution. But I’m with you, I think it’s a great idea if there were a community around it.

There is a server-side one: https://github.com/IBM/openapi-to-graphql

Not necessarily on the client side, but it’s pretty common to have a GraphQL layer in between client and one or more REST (or other) APIs that does that.

Although not GraphQL, that's the idea behind Ember-Data. The API is slightly different but you access data from serialized objects.

What you just described is exactly what a Graph implementation like Apollo is.

Reply on news.ycombinator.com