7 ms·

Migrating Netflix to GraphQL

79 points by kiyanwang 3y ago

satvikpendem 3y ago
If you know ThePrimeagen on Twitter/YouTube, he worked on Falcor (the precursor to this GraphQL change) and he talks more about it [0]. GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema: type Error { message: String! } type Query { hello(name: String!): QueryHelloResult } union QueryHelloResult = Error | QueryHelloSuccess type QueryHelloSuccess { data: String! } you can then query it with query { hello(name: "World") { __typename ... on Error { message } ... on QueryHelloSuccess { data } } } If you forget `... on Error` the query will simply fail. I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way. [0] https://www.youtube.com/watch?v=yab6i9lrEv0 https://www.youtube.com/watch?v=yab6i9lrEv0 [1] https://pothos-graphql.dev/docs/plugins/errors https://pothos-graphql.dev/docs/plugins/errors [2] https://alan.norbauer.com/articles/relay-style-graphql https://alan.norbauer.com/articles/relay-style-graphql
- foobarian 3y ago
  > Otherwise it's not too much better than REST Not sure how much on the "better" scale it counts but the server introspection with tools like GraphiQL is one of the highlights of working with GraphQL for me I don't get with other systems.
  - satvikpendem 3y ago
    Indeed, I use tools like GraphiQL all the time too, although it's not too much different than Postman for REST I suppose. But yes, being able to see all valid types and configurations of the schema as well. FYI, GraphiQL is deprecated, GraphQL Playground is a good alternative.
    - accountantbob 3y ago
      > FYI, GraphiQL is deprecated, GraphQL Playground is a good alternative. You have this backwards. https://github.com/graphql/graphql-playground/issues/1366#issuecomment-1062088978 https://github.com/graphql/graphql-playground/issues/1366#is... https://github.com/graphql/graphiql https://github.com/graphql/graphiql
      - satvikpendem 3y ago
        Ah thanks you're right, I must have mixed them up based on the older GraphiQL 1.0 I used to use.
- deepfriedrice 3y ago
  > everyone else uses GraphQL incorrectly Quite a hot take but I can't disagree. I was one of the people using GraphQL incorrectly for the longest time. I always knew something was off, that we might as well have just been using rest, but could never really articulate it. Alan's article is a great read, thanks for sharing.
  - satvikpendem 3y ago
    Indeed, I used to use Apollo for quite a while and started asking myself why I was doing this to myself, the benefits didn't seem that clear. But someone mentioned to me on /r/GraphQL about how Relay is the correct way, as Facebook initially envisioned, and once I learned it, I was hooked. Sadly, Relay usage is 1/100 the size of Apollo, even though it is literally the way GraphQL was meant to be used, so I try to talk about it wherever I can. It really is such a simple concept (list out all of the data that you need for a given part of the app, then let the compiler manage these dependencies) that is only now starting to be used in other areas, such as the GraphQL Codegen tool: https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen https://the-guild.dev/blog/unleash-the-power-of-fragments-wi.... It's still more incomplete and not as powerful but hopefully we can start integrating fragment stitching into the mainline GraphQL entities so that everyone benefits from this approach. It really reminds me of Vim, it started off being one of the best ways to write, and now 20 years later we have other editors reinventing the wheel to get closer to the Vim philosophy.
    - Exuma 3y ago
      What are the main headaches and downsides of the apollo method? i was just at this fork in the road on something i was working on
      - satvikpendem 3y ago
        I just replied to your other comment but definitely check out the article I mentioned: https://alan.norbauer.com/articles/relay-style-graphql https://alan.norbauer.com/articles/relay-style-graphql It's not so much downsides of Apollo, more so that it could be done better. Apollo does have things like the n+1 problem which are not present in Relay, so that could be considered a headache as it's annoying to solve if not using Relay.
- Exuma 3y ago
  Interesting at "apollo is not the way" can you expand more on that? im using vue with a new app im building. we proved our business idea with a 3rd party platform and im now building my own with 1 other person. I wanted to use graphql so I can make our nuxt3 app have leaner requests, and i wouldnt have to always bug the other guy to add endpoints. it was more of just an idea though, not something i have really seriously researched or considered
  - satvikpendem 3y ago
    The article I linked has much more information on the concept but essentially Apollo and most other GraphQL clients/servers don't do fragment stitching. Imagine laying out the data dependencies for each of your Vue components and having the frontend automatically refetch or cache invalidate whenever the data changes, with no input on your part. You would thus never over or underfetch your data, you get exactly the data you need at any part of your application. This is what Relay does. Relay is for React only however since Facebook made all of these technologies. I recommend using React and NextJS if you can, I used to use Vue but found that the ecosystem for non-React frameworks was still worse than React, so I switched.
    - no_wizard 3y ago
      GraphQL Yoga can do schema stitching. Its a really good project thats been around awhile too[0][1] [0]: https://the-guild.dev/graphql/yoga-server/docs https://the-guild.dev/graphql/yoga-server/docs [1]: https://the-guild.dev/graphql/stitching/docs https://the-guild.dev/graphql/stitching/docs
      - satvikpendem 3y ago
        Fragment stitching (also known as fragment colocation), not schema stitching. The Guild is starting to bring in some tools for fragment colocation, however: https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen https://the-guild.dev/blog/unleash-the-power-of-fragments-wi...
- mikecaulley 3y ago
  Thanks for the great comment. I often see GraphQL get a bad rap in comments on this site but most of the time it seems to come from a misunderstanding of how to use it.
- BLanen 3y ago
  All of this is possible with a jsonschema too. I agree that most people use GraphQL wrong because its impossible to use 'right'. Graphql 'solves' the trivial while hinting towards a future of self-describing apis and anything in between. Users will hopefully find out that GraphQL never solved any actual problems. Actual problems(valdation, (actual)error-handing, cache-invalidation being the big one in the end like usual) are kept for the user as an exercise, like always. Their promises are always not explicit but implied so the tech-enthusiasts can pick it up. I remember an article here that was talking about how GraphQL would enable apis to discover eachother on the whole internet and learn to speak to eachother without human intervention. The main selling point in the beginning was so you don't have to query fields you don't actually need to keep data transfer to a minimum. A completely trivial feature for a json api. Even a JSON api with relations is just as possible and just as easy with a JSON api. Unlike GraphQL you don't have to pretend syntax was the issue.
  - satvikpendem 3y ago
    > Actual problems(valdation, (actual)error-handing, cache-invalidation being the big one in the end like usual) are kept for the user as an exercise, like always As I mentioned elsewhere, Relay solves all of these problems automatically while people try to hack around their homegrown solution with React Query and the like. JSON Schema is tacked on as an afterthought to REST, not built in, so it's necessarily more hacky than REST.
    - BLanen 3y ago
      Yes, Relay does a good job at many of these problems. Graphql SHOULD have been Relay. Graphql without Relay is almost just a syntax.
      - satvikpendem 3y ago
        True, I will agree with you on that, and I mean, Facebook uses GraphQL just as they intended it with Relay, what are they supposed to do if others just use it as a syntax instead?
gabereiser 3y ago
Textbook example of a proper TDD practice at scale. You change the left but not the right. Clean that up and make sure it’s robust. Then change the right. Test, then test some more. Obviously novel at Netflix scale but still. The practices at the service extend to the architecture and everyone’s a winner. Good work and great write up.
candiddevmike 3y ago
Why did they migrate to GraphQL to begin with? Seems like the applications were using a REST API, what caused them to move?
- henryfjordan 3y ago
  I cant speak to Netflix's reasons, but one thing you get with GraphQL is a strongly-typed interface. REST has Swagger/OpenAPI, but it was tacked on as an afterthought and the tooling is often second-rate compared to GraphQL (which often allows you to make use of codegen). Strongly Schema'd interfaces makes client development go faster and smoother in general.
  - candiddevmike 3y ago
    It's all JSON typically, I don't think you can really compare the two that way. They're both just contracts that you hope are respected.
  - barbazoo 3y ago
    Couldn't that be dealt with by improving the tooling dev teams are using? I'm assuming a migration like the one described here are a huge effort.
    - deckard1 3y ago
      yes. If GraphQL is anything it's absolutely batteries not included. When people speak of tooling they are almost certainly talking about Apollo. I think you could probably find a similar analog in the SOAP XML days. There were lots of vendors, lots of tooling, and mostly the same challenges and outcomes. It could be as nice as you wanted if you spent the time and effort getting there. To make this more concrete, GraphQL is "strongly typed" in the sense that you get a run-time error when you use the types incorrectly. That's fine for development. Not so much for production. In order to get end-to-end typing you need to integrate with TypeScript or whatever language you're using. That has its own set of challenges. Your build process needs to know which GraphQL endpoint to use (not so easy when doing development on the API or need to use staging environments, etc.) and then generate typings based on that. Errors are another GraphQL travesty. Do you use out-of-band HTTP errors? In-band error codes? Both? (ugh, but probably once more than 1 developer touches the code). Do those errors kill your entire query? What or who determines that? I could also mention caching. But that's enough headaches for today. You need tooling just to get up to bog standard HTTP and browser caching gives you for free.
lucis 3y ago
Is GraphQL still a thing?
- switch007 3y ago
  I think a FAANG just migrated to it
- 0xbadcafebee 3y ago
  It hasn't passed the hype cycle yet.
- Osiris 3y ago
  Yes.
latchkey 3y ago
dupe: https://news.ycombinator.com/item?id=36381764 https://news.ycombinator.com/item?id=36381764 Making it to the front page again with a different query string.
_greim_ 3y ago
Until recently, an internal API framework, Falcor, powered our mobile apps. They are now backed by Federated GraphQL, a distributed approach to APIs where domain teams can independently manage and own specific sections of the API. I was an early-adopter of Falcor back when Netflix first started promoting it, and have also spent some time migrating those Falcor calls to GraphQL.
romantomjak 3y ago
I’m sceptical that migrating to GraphQL is actually an improvement. Instead of one team maintaining a cohesive API, you now have unlimited teams making shit up as they go? The article also desperately needs more context. I don’t doubt a lot of cool engineering went into making this work, but for an outsider reading the article (and without them stating any goals apart from velocity) it’s unclear whether the whole thing was just an expensive resume driven development or an actual necessity that justified the invested engineering time
- satvikpendem 3y ago
  I posted this in another comment but if you know ThePrimeagen on Twitter/YouTube, he worked on Falcor (the precursor to this GraphQL change) and he talks more about it: https://www.youtube.com/watch?v=yab6i9lrEv0 https://www.youtube.com/watch?v=yab6i9lrEv0. TLDR, monolith made it hard for them to continue adding features.
  - bnchrch 3y ago
    I personally love GraphQL but my god is that man annoying
    - hot_gril 3y ago
      The first 0.2 seconds of that video made me doubt ever using GraphQL again.
      - OJFord 3y ago
        Why do people do this, I think surely they don't behave this way in real life, but they feel the need to for YouTube? Another example that comes to mind, one I actually bared to watch some of, is Stephen Hawes (née Stephen the Robot). Great content, obviously a smart guy doing some great stuff. But every video starts over-excited 'hello my goblins and ghouls' (what?), we get crash zooms in on his face and mouth, violent music and head jerks to mark scene transitions, etc. Of course by all means have some personality, it's your video, etc., I just don't believe this is their (offline) personality? Matthias Wandel, Clough42, Marius Hornberger, and Phil's Lab I think each clearly have a certain personality that comes through, but it's 'professional', it's truly them, I assume, I think if I knew or met or worked with them in real life that they'd be exactly as I 'know' them to be. They seem genuine, and not insane.
andrewstuart 3y ago
I don’t get Graphql … what does it add, what’s better with graphql?
- adesanmi 3y ago
  My understanding is that it’s the preferred way for a lot of frontend engineers to build their experiences. It gives a lot of freedom and reduces entire classes of bugs due to the type system. Edit: to elaborate; “a lot of freedom” means an entire schema instead of pre-negotiated contracts, potentially reducing back and forth between frontend and backend.
  - tstrimple 3y ago
    Yep. Imagine an api scheme that matches the underlying normalized database structures. In order to render a view, you may need dozens of calls to different services to gather all of the data you need. Some places have been moving towards backend for front end (BFF) as a way of providing a better abstraction layer for UI development and some have been exploring GraphQL where the data can be combined and aggregated within call as dictated by the front end. I will say that the time I’ve spent working on front ends with a good graphql implementation were much more efficient and reduced overhead of dealing with more typical API interfaces. This isn’t something I’d rush into though. There is real overhead in managing graphql and in my opinion is best suited for extremely large API spaces that most companies simply don’t have to deal with. Microsoft and their graphql implementation is one where I see it as a better option than hundreds if not thousands of different services with different endpoints. https://developer.microsoft.com/en-us/graph/graph-explorer https://developer.microsoft.com/en-us/graph/graph-explorer
  - teaearlgraycold 3y ago
    I’ve done better with less: https://danangell.com/blog/posts/type-level-api-client/ https://danangell.com/blog/posts/type-level-api-client/
- pkaler 3y ago
  GraphQL makes sense when you have: - Many teams with many micorservices with many underlying stores - A fetch-based architecture Each team can be responsible for implementing the resolver for their service along with caching, scaling, etc. At Netflix's scale you don't want to have every single service have to scale to the level of the BFF/Orchestration layer. https://www.apollographql.com/docs/apollo-server/data/resolvers/ https://www.apollographql.com/docs/apollo-server/data/resolv... If you have push-based architecture, it makes more sense for underlying microservices to publish to a broker like Kafka and then materialize a view to DynamoDB, Mongo, Redis, etc. And if you don't have many teams with many microservices, then just do the REST, Rails, MVC thing and save yourself the headache.
0xbadcafebee 3y ago
GraphQL is another one of those "perfect technical solutions" that ends up being annoying as hell. Basically, managing multiple different endpoints is complicated, so they wanted to make one interface for multiple endpoints. But that one interface is now complicated, whereas before each of the multiple different endpoints was simple. I would suggest avoiding it until you're certain you need it, and consider how annoying it might be for the user. (Don't make me learn a language, then syntax check it, just to ask your API to give me some basic info)
- teaearlgraycold 3y ago
  It’s clearly one of those tools meant for big teams with big scale problems.
  - lobsterthief 3y ago
    I disagree; in my experience, it’s really great for small teams with fewer full-stack engineers. More specialized frontend engineers can rapidly iterate and prototype interfaces without needing to make corresponding API changes to endpoints, nor requesting massive payloads with a bunch of frontloaded crap. But also in my experience it’s better to go all-in on either REST or GQL; supporting both is a time suck.
- hot_gril 3y ago
  I've been down the route where GraphQL eventually becomes important after months of trying to avoid it, specifically as the main gateway for a frontend to fetch stuff. Good news is you don't have to start with it for that use case, you can add it on when it starts making sense. You sacrifice a little performance and have a small mess in the meantime, not a game-changer, so I can see the YAGNI argument. But I might start with GQL from square 1 next time. For public APIs, you have to choose further in advance whether or not to use it. Never been in that situation myself, but I'd be on the fence because I agree it's annoying for the user.
  - ysavir 3y ago
    What made GraphQL become important?
alberth 3y ago
This article seems to be missing the What and Why, and is only describing the How.
gardenhedge 3y ago
So they moved to GraphQL to get type safety but the implementation of this posed a major risk. I would have liked to be in the room for that decision making.
094459 3y ago
Great post, really enjoyed the breakdown and approach taken.
endisneigh 3y ago
Curious why there didn’t seem to be consideration for grpc, but I suppose this is the how, not why. But still, not even recalling why and alternatives considered? IMHO the strict contract that grpc makes sense if the tooling and language support can catch up.
no_wizard 3y ago
Want to give a shout out to an alternative to Apollo, which is GraphQL Yoga[0] It tends to support the latest accepted RFCs of the GraphQL spec, works with subscriptions, can do a form of federation via Schema Stitching[1] and is a blast to work with. The company behind it (The Guild) also has a service called Hive[2] that can provide analytics, schema checks, manage gateways etc. For complex cases, they also have GraphQL Mesh[3] as an alternative to Apollo Gateway [0]: https://the-guild.dev/graphql/yoga-server/docs https://the-guild.dev/graphql/yoga-server/docs [1]: https://the-guild.dev/graphql/stitching/docs https://the-guild.dev/graphql/stitching/docs [2]: https://the-guild.dev/graphql/hive https://the-guild.dev/graphql/hive [3]: https://the-guild.dev/graphql/mesh https://the-guild.dev/graphql/mesh
- deleted 3y ago
  [deleted]
- SoftwareDev6 3y ago
  ++ on the Guild. They are leaders in the GraphQL tooling space and offer a wide array of solutions. I'd also like to give a nod to Wundergraph and their Apollo Alternative. We were given early access to Cosmo[0] and so far are very happy with it. They have their own GoLang based router that is independent of Apollo, works with v1 and v2 of federation, and works with subscriptions. Comes with Studio, a CLI tool, and a OTEL Collector. So far it's been great for us at our org. [0]: https://wundergraph.com/cosmo https://wundergraph.com/cosmo
ttfkam 3y ago
Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.

79 points by kiyanwang 3y ago

If you know ThePrimeagen on Twitter/YouTube, he worked on Falcor (the precursor to this GraphQL change) and he talks more about it [0]. GraphQL is very useful, it removes whole classes of bugs. You can even use a Result/Either type where if you don't handle both the success and error cases, the GraphQL request won't even compile, so you can get type safety at both the client and the server while also not having to use purely TypeScript like with tRPC, allowing multiple clients like mobile and web. Pothos does this very well as an error extension [1], where, given the schema: type Error { message: String! } type Query { hello(name: String!): QueryHelloResult } union QueryHelloResult = Error | QueryHelloSuccess type QueryHelloSuccess { data: String! } you can then query it with query { hello(name: "World") { __typename ... on Error { message } ... on QueryHelloSuccess { data } } } If you forget `... on Error` the query will simply fail. I should also add that most people use GraphQL incorrectly, to get the benefits of not over/underfetching, the Relay approach using fragments is the only viable way currently. Otherwise it's not too much better than REST. You define the exact data required for a specific React component in GraphQL fragments, then the Relay compiler will stitch those fragments together into one and only one request. This is a great (if long) overview on the problems Relay solves and why everyone else uses GraphQL incorrectly (then complain that GraphQL sucks) [2]. Hint, Apollo is not the way. [0] https://www.youtube.com/watch?v=yab6i9lrEv0 https://www.youtube.com/watch?v=yab6i9lrEv0 [1] https://pothos-graphql.dev/docs/plugins/errors https://pothos-graphql.dev/docs/plugins/errors [2] https://alan.norbauer.com/articles/relay-style-graphql https://alan.norbauer.com/articles/relay-style-graphql

foobarian 3y ago
> Otherwise it's not too much better than REST Not sure how much on the "better" scale it counts but the server introspection with tools like GraphiQL is one of the highlights of working with GraphQL for me I don't get with other systems.
- satvikpendem 3y ago
  Indeed, I use tools like GraphiQL all the time too, although it's not too much different than Postman for REST I suppose. But yes, being able to see all valid types and configurations of the schema as well. FYI, GraphiQL is deprecated, GraphQL Playground is a good alternative.
  - accountantbob 3y ago
    > FYI, GraphiQL is deprecated, GraphQL Playground is a good alternative. You have this backwards. https://github.com/graphql/graphql-playground/issues/1366#issuecomment-1062088978 https://github.com/graphql/graphql-playground/issues/1366#is... https://github.com/graphql/graphiql https://github.com/graphql/graphiql
    - satvikpendem 3y ago
      Ah thanks you're right, I must have mixed them up based on the older GraphiQL 1.0 I used to use.
deepfriedrice 3y ago
> everyone else uses GraphQL incorrectly Quite a hot take but I can't disagree. I was one of the people using GraphQL incorrectly for the longest time. I always knew something was off, that we might as well have just been using rest, but could never really articulate it. Alan's article is a great read, thanks for sharing.
- satvikpendem 3y ago
  Indeed, I used to use Apollo for quite a while and started asking myself why I was doing this to myself, the benefits didn't seem that clear. But someone mentioned to me on /r/GraphQL about how Relay is the correct way, as Facebook initially envisioned, and once I learned it, I was hooked. Sadly, Relay usage is 1/100 the size of Apollo, even though it is literally the way GraphQL was meant to be used, so I try to talk about it wherever I can. It really is such a simple concept (list out all of the data that you need for a given part of the app, then let the compiler manage these dependencies) that is only now starting to be used in other areas, such as the GraphQL Codegen tool: https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen https://the-guild.dev/blog/unleash-the-power-of-fragments-wi.... It's still more incomplete and not as powerful but hopefully we can start integrating fragment stitching into the mainline GraphQL entities so that everyone benefits from this approach. It really reminds me of Vim, it started off being one of the best ways to write, and now 20 years later we have other editors reinventing the wheel to get closer to the Vim philosophy.
  - Exuma 3y ago
    What are the main headaches and downsides of the apollo method? i was just at this fork in the road on something i was working on
    - satvikpendem 3y ago
      I just replied to your other comment but definitely check out the article I mentioned: https://alan.norbauer.com/articles/relay-style-graphql https://alan.norbauer.com/articles/relay-style-graphql It's not so much downsides of Apollo, more so that it could be done better. Apollo does have things like the n+1 problem which are not present in Relay, so that could be considered a headache as it's annoying to solve if not using Relay.
Exuma 3y ago
Interesting at "apollo is not the way" can you expand more on that? im using vue with a new app im building. we proved our business idea with a 3rd party platform and im now building my own with 1 other person. I wanted to use graphql so I can make our nuxt3 app have leaner requests, and i wouldnt have to always bug the other guy to add endpoints. it was more of just an idea though, not something i have really seriously researched or considered
- satvikpendem 3y ago
  The article I linked has much more information on the concept but essentially Apollo and most other GraphQL clients/servers don't do fragment stitching. Imagine laying out the data dependencies for each of your Vue components and having the frontend automatically refetch or cache invalidate whenever the data changes, with no input on your part. You would thus never over or underfetch your data, you get exactly the data you need at any part of your application. This is what Relay does. Relay is for React only however since Facebook made all of these technologies. I recommend using React and NextJS if you can, I used to use Vue but found that the ecosystem for non-React frameworks was still worse than React, so I switched.
  - no_wizard 3y ago
    GraphQL Yoga can do schema stitching. Its a really good project thats been around awhile too[0][1] [0]: https://the-guild.dev/graphql/yoga-server/docs https://the-guild.dev/graphql/yoga-server/docs [1]: https://the-guild.dev/graphql/stitching/docs https://the-guild.dev/graphql/stitching/docs
    - satvikpendem 3y ago
      Fragment stitching (also known as fragment colocation), not schema stitching. The Guild is starting to bring in some tools for fragment colocation, however: https://the-guild.dev/blog/unleash-the-power-of-fragments-with-graphql-codegen https://the-guild.dev/blog/unleash-the-power-of-fragments-wi...
mikecaulley 3y ago
Thanks for the great comment. I often see GraphQL get a bad rap in comments on this site but most of the time it seems to come from a misunderstanding of how to use it.
BLanen 3y ago
All of this is possible with a jsonschema too. I agree that most people use GraphQL wrong because its impossible to use 'right'. Graphql 'solves' the trivial while hinting towards a future of self-describing apis and anything in between. Users will hopefully find out that GraphQL never solved any actual problems. Actual problems(valdation, (actual)error-handing, cache-invalidation being the big one in the end like usual) are kept for the user as an exercise, like always. Their promises are always not explicit but implied so the tech-enthusiasts can pick it up. I remember an article here that was talking about how GraphQL would enable apis to discover eachother on the whole internet and learn to speak to eachother without human intervention. The main selling point in the beginning was so you don't have to query fields you don't actually need to keep data transfer to a minimum. A completely trivial feature for a json api. Even a JSON api with relations is just as possible and just as easy with a JSON api. Unlike GraphQL you don't have to pretend syntax was the issue.
- satvikpendem 3y ago
  > Actual problems(valdation, (actual)error-handing, cache-invalidation being the big one in the end like usual) are kept for the user as an exercise, like always As I mentioned elsewhere, Relay solves all of these problems automatically while people try to hack around their homegrown solution with React Query and the like. JSON Schema is tacked on as an afterthought to REST, not built in, so it's necessarily more hacky than REST.
  - BLanen 3y ago
    Yes, Relay does a good job at many of these problems. Graphql SHOULD have been Relay. Graphql without Relay is almost just a syntax.
    - satvikpendem 3y ago
      True, I will agree with you on that, and I mean, Facebook uses GraphQL just as they intended it with Relay, what are they supposed to do if others just use it as a syntax instead?

gabereiser 3y ago

Textbook example of a proper TDD practice at scale. You change the left but not the right. Clean that up and make sure it’s robust. Then change the right. Test, then test some more. Obviously novel at Netflix scale but still. The practices at the service extend to the architecture and everyone’s a winner. Good work and great write up.

candiddevmike 3y ago

Why did they migrate to GraphQL to begin with? Seems like the applications were using a REST API, what caused them to move?

henryfjordan 3y ago
I cant speak to Netflix's reasons, but one thing you get with GraphQL is a strongly-typed interface. REST has Swagger/OpenAPI, but it was tacked on as an afterthought and the tooling is often second-rate compared to GraphQL (which often allows you to make use of codegen). Strongly Schema'd interfaces makes client development go faster and smoother in general.
- candiddevmike 3y ago
  It's all JSON typically, I don't think you can really compare the two that way. They're both just contracts that you hope are respected.
- barbazoo 3y ago
  Couldn't that be dealt with by improving the tooling dev teams are using? I'm assuming a migration like the one described here are a huge effort.
  - deckard1 3y ago
    yes. If GraphQL is anything it's absolutely batteries not included. When people speak of tooling they are almost certainly talking about Apollo. I think you could probably find a similar analog in the SOAP XML days. There were lots of vendors, lots of tooling, and mostly the same challenges and outcomes. It could be as nice as you wanted if you spent the time and effort getting there. To make this more concrete, GraphQL is "strongly typed" in the sense that you get a run-time error when you use the types incorrectly. That's fine for development. Not so much for production. In order to get end-to-end typing you need to integrate with TypeScript or whatever language you're using. That has its own set of challenges. Your build process needs to know which GraphQL endpoint to use (not so easy when doing development on the API or need to use staging environments, etc.) and then generate typings based on that. Errors are another GraphQL travesty. Do you use out-of-band HTTP errors? In-band error codes? Both? (ugh, but probably once more than 1 developer touches the code). Do those errors kill your entire query? What or who determines that? I could also mention caching. But that's enough headaches for today. You need tooling just to get up to bog standard HTTP and browser caching gives you for free.

lucis 3y ago

Is GraphQL still a thing?

switch007 3y ago
I think a FAANG just migrated to it
0xbadcafebee 3y ago
It hasn't passed the hype cycle yet.
Osiris 3y ago
Yes.

latchkey 3y ago

dupe: https://news.ycombinator.com/item?id=36381764 https://news.ycombinator.com/item?id=36381764 Making it to the front page again with a different query string.

_greim_ 3y ago

Until recently, an internal API framework, Falcor, powered our mobile apps. They are now backed by Federated GraphQL, a distributed approach to APIs where domain teams can independently manage and own specific sections of the API. I was an early-adopter of Falcor back when Netflix first started promoting it, and have also spent some time migrating those Falcor calls to GraphQL.

romantomjak 3y ago

I’m sceptical that migrating to GraphQL is actually an improvement. Instead of one team maintaining a cohesive API, you now have unlimited teams making shit up as they go? The article also desperately needs more context. I don’t doubt a lot of cool engineering went into making this work, but for an outsider reading the article (and without them stating any goals apart from velocity) it’s unclear whether the whole thing was just an expensive resume driven development or an actual necessity that justified the invested engineering time

satvikpendem 3y ago
I posted this in another comment but if you know ThePrimeagen on Twitter/YouTube, he worked on Falcor (the precursor to this GraphQL change) and he talks more about it: https://www.youtube.com/watch?v=yab6i9lrEv0 https://www.youtube.com/watch?v=yab6i9lrEv0. TLDR, monolith made it hard for them to continue adding features.
- bnchrch 3y ago
  I personally love GraphQL but my god is that man annoying
  - hot_gril 3y ago
    The first 0.2 seconds of that video made me doubt ever using GraphQL again.
    - OJFord 3y ago
      Why do people do this, I think surely they don't behave this way in real life, but they feel the need to for YouTube? Another example that comes to mind, one I actually bared to watch some of, is Stephen Hawes (née Stephen the Robot). Great content, obviously a smart guy doing some great stuff. But every video starts over-excited 'hello my goblins and ghouls' (what?), we get crash zooms in on his face and mouth, violent music and head jerks to mark scene transitions, etc. Of course by all means have some personality, it's your video, etc., I just don't believe this is their (offline) personality? Matthias Wandel, Clough42, Marius Hornberger, and Phil's Lab I think each clearly have a certain personality that comes through, but it's 'professional', it's truly them, I assume, I think if I knew or met or worked with them in real life that they'd be exactly as I 'know' them to be. They seem genuine, and not insane.

andrewstuart 3y ago

I don’t get Graphql … what does it add, what’s better with graphql?

adesanmi 3y ago
My understanding is that it’s the preferred way for a lot of frontend engineers to build their experiences. It gives a lot of freedom and reduces entire classes of bugs due to the type system. Edit: to elaborate; “a lot of freedom” means an entire schema instead of pre-negotiated contracts, potentially reducing back and forth between frontend and backend.
- tstrimple 3y ago
  Yep. Imagine an api scheme that matches the underlying normalized database structures. In order to render a view, you may need dozens of calls to different services to gather all of the data you need. Some places have been moving towards backend for front end (BFF) as a way of providing a better abstraction layer for UI development and some have been exploring GraphQL where the data can be combined and aggregated within call as dictated by the front end. I will say that the time I’ve spent working on front ends with a good graphql implementation were much more efficient and reduced overhead of dealing with more typical API interfaces. This isn’t something I’d rush into though. There is real overhead in managing graphql and in my opinion is best suited for extremely large API spaces that most companies simply don’t have to deal with. Microsoft and their graphql implementation is one where I see it as a better option than hundreds if not thousands of different services with different endpoints. https://developer.microsoft.com/en-us/graph/graph-explorer https://developer.microsoft.com/en-us/graph/graph-explorer
- teaearlgraycold 3y ago
  I’ve done better with less: https://danangell.com/blog/posts/type-level-api-client/ https://danangell.com/blog/posts/type-level-api-client/
pkaler 3y ago
GraphQL makes sense when you have: - Many teams with many micorservices with many underlying stores - A fetch-based architecture Each team can be responsible for implementing the resolver for their service along with caching, scaling, etc. At Netflix's scale you don't want to have every single service have to scale to the level of the BFF/Orchestration layer. https://www.apollographql.com/docs/apollo-server/data/resolvers/ https://www.apollographql.com/docs/apollo-server/data/resolv... If you have push-based architecture, it makes more sense for underlying microservices to publish to a broker like Kafka and then materialize a view to DynamoDB, Mongo, Redis, etc. And if you don't have many teams with many microservices, then just do the REST, Rails, MVC thing and save yourself the headache.

0xbadcafebee 3y ago

GraphQL is another one of those "perfect technical solutions" that ends up being annoying as hell. Basically, managing multiple different endpoints is complicated, so they wanted to make one interface for multiple endpoints. But that one interface is now complicated, whereas before each of the multiple different endpoints was simple. I would suggest avoiding it until you're certain you need it, and consider how annoying it might be for the user. (Don't make me learn a language, then syntax check it, just to ask your API to give me some basic info)

teaearlgraycold 3y ago
It’s clearly one of those tools meant for big teams with big scale problems.
- lobsterthief 3y ago
  I disagree; in my experience, it’s really great for small teams with fewer full-stack engineers. More specialized frontend engineers can rapidly iterate and prototype interfaces without needing to make corresponding API changes to endpoints, nor requesting massive payloads with a bunch of frontloaded crap. But also in my experience it’s better to go all-in on either REST or GQL; supporting both is a time suck.
hot_gril 3y ago
I've been down the route where GraphQL eventually becomes important after months of trying to avoid it, specifically as the main gateway for a frontend to fetch stuff. Good news is you don't have to start with it for that use case, you can add it on when it starts making sense. You sacrifice a little performance and have a small mess in the meantime, not a game-changer, so I can see the YAGNI argument. But I might start with GQL from square 1 next time. For public APIs, you have to choose further in advance whether or not to use it. Never been in that situation myself, but I'd be on the fence because I agree it's annoying for the user.
- ysavir 3y ago
  What made GraphQL become important?

alberth 3y ago

This article seems to be missing the What and Why, and is only describing the How.

gardenhedge 3y ago

So they moved to GraphQL to get type safety but the implementation of this posed a major risk. I would have liked to be in the room for that decision making.

094459 3y ago

Great post, really enjoyed the breakdown and approach taken.

endisneigh 3y ago

Curious why there didn’t seem to be consideration for grpc, but I suppose this is the how, not why. But still, not even recalling why and alternatives considered? IMHO the strict contract that grpc makes sense if the tooling and language support can catch up.

no_wizard 3y ago

Want to give a shout out to an alternative to Apollo, which is GraphQL Yoga[0] It tends to support the latest accepted RFCs of the GraphQL spec, works with subscriptions, can do a form of federation via Schema Stitching[1] and is a blast to work with. The company behind it (The Guild) also has a service called Hive[2] that can provide analytics, schema checks, manage gateways etc. For complex cases, they also have GraphQL Mesh[3] as an alternative to Apollo Gateway [0]: https://the-guild.dev/graphql/yoga-server/docs https://the-guild.dev/graphql/yoga-server/docs [1]: https://the-guild.dev/graphql/stitching/docs https://the-guild.dev/graphql/stitching/docs [2]: https://the-guild.dev/graphql/hive https://the-guild.dev/graphql/hive [3]: https://the-guild.dev/graphql/mesh https://the-guild.dev/graphql/mesh

deleted 3y ago
[deleted]
SoftwareDev6 3y ago
++ on the Guild. They are leaders in the GraphQL tooling space and offer a wide array of solutions. I'd also like to give a nod to Wundergraph and their Apollo Alternative. We were given early access to Cosmo[0] and so far are very happy with it. They have their own GoLang based router that is independent of Apollo, works with v1 and v2 of federation, and works with subscriptions. Comes with Studio, a CLI tool, and a OTEL Collector. So far it's been great for us at our org. [0]: https://wundergraph.com/cosmo https://wundergraph.com/cosmo

ttfkam 3y ago

Postgraphile https://postgraphile.org/ https://postgraphile.org/ Hasura https://hasura.io/ https://hasura.io/ Stop writing GraphQL resolvers by hand, especially if you're working off of a relational database model.