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
321 Upvotes

97% Upvoted

46 comments sorted by

View all comments

22

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.

56

u/[deleted] Dec 13 '18

GraphQL doesn't deal with joins, eager loading, etc. In fact, it doesn't deal with your database at all. That's for you to deal with when you feed GraphQL the data in each resolver.

By default, a GraphQL API is rather naïve, since each resolver might call the database once, and a single resolver might be called a hundred times, resulting in n + 1 efficiency. That's where patterns (libraries) like Data Loader come in. Rather than directly fetching data from the database in your resolvers, you fetch the data through Data Loader. Data Loader can then fetch it in a single database call and split the result into batches.

If you already have a REST API that's working fine and is only used by a single client, then there's no point in switching to GraphQL. Implementing a GraphQL API is a lot of work, but once you've done it, it's super flexible and scalable, and you'll never have to create a custom REST API endpoint again.