TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Seamlessly Swapping the API back end of the Netflix Android app

56 点作者 bhaavan超过 4 年前

3 条评论

nhoughto超过 4 年前
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
评论 #24866518 未加载
评论 #24868410 未加载
jFriedensreich超过 4 年前
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&#x2F;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.
e12e超过 4 年前
&gt; 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&#x27;t go with a microservice on top of kotlin? I mean, nodejs is ok - but it&#x27;s not like it&#x27;s not possible to write a microservice backed by an uberjar?