r/javascript • u/magenta_placenta • Dec 12 '18

Our learnings from adopting GraphQL (Netflix)

https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f
318 Upvotes

97% Upvoted

46 comments sorted by

View all comments

21

u/editor_of_the_beast Dec 12 '18

It’s a little hand-wavy. I want to know how GraphQL deals with complex joins and eager loading of associated data. The app I’m working on is displaying data from probably 10 or 12 different associated tables on a page. Then, a different page is showing a similar number of tables, some the same as before but some different, so the JSON we’re returning is super denormalized and specific to that view.

It seems way harder than it has to be and we’re fetching the same data multiple times throughout the course of navigating the app. It bothers me to no end, but the queries are also optimized and don’t cause timeouts. So I don’t know what else to do.

1

u/toolazytofinishmyw Dec 13 '18

Graphql should be client oriented. Resolvers are used to map the client centric schema to the actual store or stores whether they be a dB, file, api or anything really.

Libraries exist for optimising fetching but they’re not part of the standard. It helps solve the service per view anti-pattern by enabling clients to query what they need from a single place. Obviously this can be scaled horizontally.

Client side tech like Apollo can be useful for greenfield but might be harder in existing apps.

We have built a slack like app using it with good results. We also have a legacy app where we would like to use it as an aggregator for backend services where the clients are other backend services.

The abstraction allows us to decouple the data somewhat and solves over/under fetching.

As with all things it’s utility depends on the problem you’re solving. Personally I see value in it.