I’ve been reading more of the Netflix engineering blog recently (got in a clickhole), what strikes about their more recent articles as they seem to be creating technical solutions (like BFF and friends) for what could essentially be process or coordination problems, and that is less exciting to me.<p>Sometimes you don’t own the whole thing and BFF is the best way, but in my mind that place wasn’t Netflix, but some slow moving bank etc
I really love falcor, though it seems to be quite underground outside of netflix these days. I dearly hope they keep open sourcing falcor stuff!<p>My company uses falcor exclusively for 2 years in the datalayer and it has major advantages for us compared to graphql or other alternatives:<p>- has all the features to expect from modern data layer (caching incl. invalidation and refreshing, request batching, pluggable transport protocol, error handling, endpoint stitching, delegation, handling of references, reactivity)<p>- much simpler to reason about, focus on the core features<p>- much more flexible for certain usecases, because the schema can change/evolve dynamically (really cool for rapid prototyping etc.)<p>- the query model (paths and path sets) is much closer to javascript and json than for graphql (also no need to parse and build a fairly complex query language string ). This allows us to gernerate nearly all queries automatcally from templates. Imagine apollo, but without any need to maunually define useQuery in the head of a component. This is really THE killer feature of falcor.
> As Android developers, we’ve come to rely on the safety of a strongly typed language like Kotlin, maybe with a side of Java. Since this new microservice uses Node.js, we had to write our endpoints in Javascript (...)<p>I wonder why they didn't go with a microservice on top of kotlin? I mean, nodejs is ok - but it's not like it's not possible to write a microservice backed by an uberjar?