
Netflix - Our learnings from adopting GraphQL - sahin-boydas
https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f
======
WorldMaker
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.

------
johnsonjo
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.

------
obilgic

        We also considered Falcor...
    

Didn't netflix create Falcor ...?

~~~
johnsonjo
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.

