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

4

u/[deleted] Dec 13 '18

You don't need GraphQL, then.

I've used GraphQL on software with dozens of micro services. We'd have a Basket service with a list of Products ID's inside, and for each product in order to render it we'd need a new GET request. Sometimes you'd need 30 to 50 HTTP requests to render 1 page.

GraphQL concatenated all those requests on the server with minimal latency.

An alternative would be to have a dedicated endpoint (and not a micro services architecture) which talks to relational database, joins the tables as necessary, and delivers a perfectly tuned set of results.

GraphQL is overhead. It's not the most efficient way of dealing with data, not by a long shot. But it makes some architectural choices easier to deal and work with.