4 ms·

Netflix - Our learnings from adopting GraphQL

14 points by sahin-boydas 8y ago

WorldMaker 8y ago
This article mentions Falcor, which leaves me wondering what the future is of Falcor. It does seem like Falcor and GraphQL cover very similar ground, and with GraphQL adoption on the rise, perhaps its time to consider it the winner of the fight? Not that's it has to be a Highlander-style battle where there can only be one, but it might be a good idea to see something of a merge/quickening here. Some of the JSON Graph stuff in Falcor would be great to see officially added to the GraphQL spec, for instance. I've seen several incompatible approaches for describing "normalized"/"shared"/"deduped" data in GraphQL and something like Falcor's JSON Graph References would be useful to have as a more official API or API extension in GraphQL.
obilgic 8y ago
We also considered Falcor... Didn't netflix create Falcor ...?
- johnsonjo 8y ago
  Yep. If you click the link it links to a domain containing Netflix. I’ve also heard previously that Netflix created Falcor before GraphQL existed, so it makes sense that they might evualuate a new tool.
johnsonjo 8y ago
I’ve got to say, I have been trying out GraphQL and Apollo in a GRAND stack app on a new project and once you get up to speed with it it is an absolute pleasure to work with. Here’s some benefits and a bit of an overview of GraphQL and Apollo. First think of GraphQL as a competing ideology for REST API endpoints. With GraphQL, you only collect data you need which they say in terms of no over or under fetching of data happens. In making a request it is visibly apparent how your data is shaped meaning you know what properties would be defined when you chain them together. You have to create a schema and in this schema you define the types of each objects’ properties (this should not replace database schemas, but should basically define how data should enter and exit from your GraphQL endpoint to your client.) There are two types of schema types mainly ‘type’s which are models for data that can be queried and ‘input’s which are models for data that can be inputs for data creation and modifications. This leads to the only two types of queries namely ‘queries’ and ‘mutations’. There is also only a single endpoint for all types of queries including mutations, so you don’t have to try and remember all the different ones. I guess the equivalent of remembering routes is remembering the names of mutations you make, but this is aided by intellisense and the easily searchable schema from the playground. My favorite part is the tooling. For example the GraphQL playground which is provided by Apollo Server allows you to have the equivelant of intellisense for your queries it lists and autocompletes what properties are on a given branch/property of the type you are requesting. Another benefit to the playground is you can view and search your schema and follow links between different types. This tooling makes development pleasurable, and is no doubt able to be made due to the design decisions that GraphQL made. A few other neat things that I know are true of Apollo server but am not sure if they are in the GraphQL spec is that your return values from your resolvers (resolvers are like route handlers in rest, but they are specific to the types in your schema) become your response to your client. Asynchronous values (e.g. Promises) are waited on before being sent back as a response. Uncaught errors thrown in resolvers are automatically handled and sent back to the client. Overall it’s starting to make me like having more type safety than JavaScript typically has. Also using Apollo client with React is really nice and fills a good gap for adding model and controller layers to React’s view layer, so you don’t really need Redux or the like with Apollo client.

14 points by sahin-boydas 8y ago

This article mentions Falcor, which leaves me wondering what the future is of Falcor. It does seem like Falcor and GraphQL cover very similar ground, and with GraphQL adoption on the rise, perhaps its time to consider it the winner of the fight? Not that's it has to be a Highlander-style battle where there can only be one, but it might be a good idea to see something of a merge/quickening here. Some of the JSON Graph stuff in Falcor would be great to see officially added to the GraphQL spec, for instance. I've seen several incompatible approaches for describing "normalized"/"shared"/"deduped" data in GraphQL and something like Falcor's JSON Graph References would be useful to have as a more official API or API extension in GraphQL.

obilgic 8y ago

We also considered Falcor... Didn't netflix create Falcor ...?

johnsonjo 8y ago
Yep. If you click the link it links to a domain containing Netflix. I’ve also heard previously that Netflix created Falcor before GraphQL existed, so it makes sense that they might evualuate a new tool.

johnsonjo 8y ago

I’ve got to say, I have been trying out GraphQL and Apollo in a GRAND stack app on a new project and once you get up to speed with it it is an absolute pleasure to work with. Here’s some benefits and a bit of an overview of GraphQL and Apollo. First think of GraphQL as a competing ideology for REST API endpoints. With GraphQL, you only collect data you need which they say in terms of no over or under fetching of data happens. In making a request it is visibly apparent how your data is shaped meaning you know what properties would be defined when you chain them together. You have to create a schema and in this schema you define the types of each objects’ properties (this should not replace database schemas, but should basically define how data should enter and exit from your GraphQL endpoint to your client.) There are two types of schema types mainly ‘type’s which are models for data that can be queried and ‘input’s which are models for data that can be inputs for data creation and modifications. This leads to the only two types of queries namely ‘queries’ and ‘mutations’. There is also only a single endpoint for all types of queries including mutations, so you don’t have to try and remember all the different ones. I guess the equivalent of remembering routes is remembering the names of mutations you make, but this is aided by intellisense and the easily searchable schema from the playground. My favorite part is the tooling. For example the GraphQL playground which is provided by Apollo Server allows you to have the equivelant of intellisense for your queries it lists and autocompletes what properties are on a given branch/property of the type you are requesting. Another benefit to the playground is you can view and search your schema and follow links between different types. This tooling makes development pleasurable, and is no doubt able to be made due to the design decisions that GraphQL made. A few other neat things that I know are true of Apollo server but am not sure if they are in the GraphQL spec is that your return values from your resolvers (resolvers are like route handlers in rest, but they are specific to the types in your schema) become your response to your client. Asynchronous values (e.g. Promises) are waited on before being sent back as a response. Uncaught errors thrown in resolvers are automatically handled and sent back to the client. Overall it’s starting to make me like having more type safety than JavaScript typically has. Also using Apollo client with React is really nice and fills a good gap for adding model and controller layers to React’s view layer, so you don’t really need Redux or the like with Apollo client.