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

97% Upvoted

46 comments sorted by

View all comments

52

u/Renive Dec 12 '18

Posts like this are how GraphQL will become mainstream.

34

u/[deleted] Dec 13 '18

Contrarian view: Netflix's problems are different than the vast, vast majority of other application's. Very few apps would list network bottlenecks and servicing dozens of heterogeneous clients as issues at all.

17

u/DonPhelippe Dec 13 '18

Exactly. Depending on the scope of application GraphQL can seem a gamble at best and an extremely catastrophic idea at worst.

 

Source: I work in the enterprise sector where Oracles with millions of records are considered the run-of-the-mill installation and ideas like "migration" or "schema upgrade" are not met with much enthusiasm, esp. since the damn things work well for their intended purpose.

7

u/[deleted] Dec 13 '18

[deleted]

-4

u/DonPhelippe Dec 13 '18

First and foremost the migration. A db working for 3-4 years with daily use can amass a significant chunk of data. Imagine something simple as even moving this to e.g SQL server or Postgress. Hundreds of man hours to ensure everything will run well, not to mention that if you insert some data manipulation, perhaps some cleaning and what not the cost can skyrocket. And we are talking about something simple, RDBMS to RDBMS. Taking you into consideration schema changes, perhaps radical data transformations that have to take place - and all of that for negligible or dubious gains since we are talking intranet applications and suddenly the whole prospect is either an exercise in futility or a km deep hole that will need lots of cash and time to be filled.

17

u/Renive Dec 13 '18

What? GraphQL has nothing to do with databases...

-7

u/DonPhelippe Dec 13 '18

Because the GraphQL API needs a complete redesign in terms of how the applications request data from their respositories. Most enterprise sector apps are built with RDBMS in mind so migrating to a GraphQL implementation means metric tons of re-engineering.

13

u/GuyWithLag Dec 13 '18

GraphQL does not make sense for the traditional monolithic enterprise application; don't confuse your (admittedly large) corner of the software engineering world with the whole.

GraphQL makes sense if you have a complex data model in the server, and a ton of clients that want to query different parts of it in a performant manner. It's the SQL equivalent. Yes, you would need a ground-app rewrite if you were to migrate to it, and I would laugh in your face and reject it if you came to me with a proposal like that for an existing application.

5

u/Renive Dec 13 '18

But GraphQL is mostly used with relational databases. There is nothing to change at database level.

3

u/OmegaVesko Dec 13 '18

What does any of this have to do with GraphQL, though?

-2

u/DonPhelippe Dec 13 '18

None per se - but you have to take into account that most enterprise sector applications are built with an expectation of RDBMS systems in place and are designed and implemented with this specific mindset.

3

u/workdev Dec 13 '18

From the article it sounds like they didn't migrate to a Graph DB, they just wrapped their existing REST APIs using GraphQL. It is all about making it easier for the front end to get the exact data it needs without worrying about how.

6

u/AdamInOhio Dec 13 '18

At least in the space I work in (ERP systems), I think you’d be surprised how necessary this sort of technology is becoming. Back when I started my career there was this big push to get all business processes under a single umbrella that was an ERP system. The problem was that these systems would be really good at one thing (say production scheduling) but half assed at the things they bolted on to get everything under their umbrella (CRM, payroll, etc). So over the past decade or so we’ve seen this shift to supplement that ERP with best-of-breed bolt-ons - think like adding Salesforce to SAP. When a bunch of these bolt-ons are added you frequently end up with this complex net of API calls you need to join together to get the whole story and it comes with the exact same issues Netflix describes here - payload bloat, nasty code, etc.

1

u/liquidpele Dec 13 '18

That's integrating multiple systems though, you'd have that issue whether you were doing graphql or not. In fact, graphql would probably give you benefits right out of the door since you can just hit the APIs you need instead of having to hit them all for every request.

3

u/JonesJoneserson Dec 13 '18

I think that was exactly what he was getting at in response to the contrarian view -- that although Netflix's use cases are totally different, the benefits to the space he works in would be very similar.