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.
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 got that feeling too when reading the article. They said a common frontend for all app platforms does not work and then state they use Falcor for the android app. There is no reason they couldnt use Falcor for the ios platforms too.
Looks a bit like not invented here (in this team) syndrome
I still don't really get this, if they're using GraphQL which it appears they are with Falcor why do they need a specific microservices for every client? Can the data that each client needs not be queried ad-hoc?
falcor uses a GraphQL alternative called jsonGraph which has overlapping features and usecases but is a completely seperate technology. The decision to have seperate services per app has nothing to do with the technology but with the politics of structuring teams and evolving technology at netflix.
OK, haven't read anything about falcor since it's annoucement I always assumed it was GraphQL based. So the point is to not need to wait on team X to deliver feature Y? Rather the client teams are responsible for implementing whatever they need? I think I got it.
> 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 (...)
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?
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!
My company uses falcor exclusively for 2 years in the datalayer and it has major advantages for us compared to graphql or other alternatives:
- 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)
- much simpler to reason about, focus on the core features
- much more flexible for certain usecases, because the schema can change/evolve dynamically (really cool for rapid prototyping etc.)
- 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.
8 comments
[ 0.20 ms ] story [ 30.3 ms ] threadSometimes 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
Looks a bit like not invented here (in this team) syndrome
Ed: was open sourced back in 2015 - discussion at the time: https://news.ycombinator.com/item?id=10075092
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?
My company uses falcor exclusively for 2 years in the datalayer and it has major advantages for us compared to graphql or other alternatives:
- 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)
- much simpler to reason about, focus on the core features
- much more flexible for certain usecases, because the schema can change/evolve dynamically (really cool for rapid prototyping etc.)
- 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.