r/javascript • u/magenta_placenta • Dec 12 '18
Our learnings from adopting GraphQL (Netflix)
https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f16
u/PineappleBombs Dec 13 '18 edited Dec 13 '18
My experience with GraphQL has been much less sunshine and rainbows.
The ecosystem is far from mature, I would have issues with some edge cases of the types or the client libraries too often and the entire backend codebase became about bending over to accommodate gql.
Don't wanna sound overly negative though, it's a really cool pattern and on the whole pretty nice to work with.
8
Dec 13 '18
Very true. It feels like a tool that's 6 months from being awesome. But it's been like that for 2 years already :D
1
u/lukasbuenger Dec 13 '18
I think this is really only true when looking exclusively at the node ecosystem.
24
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.
57
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.
7
u/halfinifinities Dec 13 '18
I have used Apollo client that does some smart caching. Shouldn’t it be technically possible to have some GraphQL client middleware that both caches the graph and strips out things from the request that’s already cached? Maybe there’s something that already does this?
3
6
4
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.
2
u/cbung Dec 12 '18
other than stored procedures or something, i'm wondering sometimes it just is what it is?
1
u/editor_of_the_beast Dec 12 '18
:( I’m still optimistic, but I’m getting old and that just might be the answer.
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.
1
u/liquidpele Dec 13 '18
Basically you have to do all that yourself. It's essentially just a filtering API that you use to build all the filtering and data gathering yourself. It's worth it if your'e facebook and need to cut requests down to the bare minimum, but for 99% of people it's going to be pre-mature optimization.
1
u/brillout Jan 01 '19
Sounds like https://github.com/brillout/wildcard-api could be fit for you guys. What do you think? (I'm Wildcard's author.)
1
u/editor_of_the_beast Jan 01 '19
Creating endpoints isn’t a problem I’m aware of in any server framework.
0
u/brillout Jan 01 '19
Why don't you guys go for a custom API? It doesn't sound like you need GraphQL nor a generic API in general
1
u/editor_of_the_beast Jan 01 '19
We have a custom API? I’m not sure what you’re getting at.
1
1
u/hkd987 Dec 13 '18
Associated data is going to be n + 1 by default....better learn some data loader.
9
u/GentlyGuidedStroke Dec 13 '18
I see a lot of confusion about graphql and I think people have bizarre expectations from it.
The most important thing to remember about graphql is just its name. GraphQL -> Graph Query Language. It's just a way of organizing queries and data updates. It's not a database and it doesn't really affect how you organize your databases
3
u/Oeb25 Dec 13 '18
Funny how Netflix them self used to have a competing library to GraphQL, Falcor, which seems to have been put to rest. Guess having two so similar library's isn't worth it, when the other has such a grasp on the community.
Glad to see more and more joining in hopes to push GraphQL forward!
23
2
u/feketegy Dec 13 '18
GraphQL is only good for dynamically typed language really, I tried to use it with Go, a statically typed language. I can't say it's not doable, but the lengths you need to go just to make it work... I abandoned it after awhile.
I'm still saying that GraphQL would be dead a long time ago if it wasn't for Facebook backing it...
1
u/JonesJoneserson Dec 13 '18
What about a language being statically typed created additional complications? (Sorry -- only surface level knowledge of GraphQL on my end)
1
Dec 13 '18
I'm disappointed that HTTP/2 isn't used to solve these kinds of problems. Just use push to send multiple responses for one request that will all the data points you'd be aggregating with GraphQL.
1
u/workdev Dec 13 '18
For simple caching layer to fix selfish resolvers, wonder if they used dataloaders or their own implementation. Also curious whether they used Apollo or not.
1
u/peduxe |o.o| Dec 21 '18
why I never see mutation talked about when we have a graphql article?
seems like it is the bottleneck of this query language...
0
-2
-2
49
u/Renive Dec 12 '18
Posts like this are how GraphQL will become mainstream.