原文链接
湾区日报翻译 by zzq
简评
从传统的Rails app、服务器端渲染网页，进化到时髦的React + Redux的single page app；文中有动图有代码，感受一下这家十岁的“创业”公司的代码库成长的烦恼. （摘自湾区日报）
概述：我们最近重新考虑了Airbnb网站代码库的JavaScript部分的架构。这篇文章将分析（1）诱发这些变化的产品上的驱动（2）我们如何一步步离开之前Rails的解决方案（3）新技术栈的核心。福利：我们将讨论下一代前端技术。
Airbnb网站每天有超过7500万的搜索，这使得搜索页面成流量最大的页面。在过去的将近十年里，工程师们一直致力于改进、加强、优化Rails传送页面的方式。
最近，我们首页变成了垂直风格，从上到下依次为首页，体验介绍和场地。作为把新产品上线的一部分，我们重新思考了搜索体验。
之前我们的搜索是先把用户从首页引导至搜索结果页面，然后是用户进入某个列表项的详情页面，然后是预定流程。每个页面都是Rail进行一次单独的页面传送。现在我们希望用户能有一个更流畅的体验，根据用户的行为调整用户的体验并窄化他们的搜索。
在多个Tab间导航和与列表交互感觉应该是很炫酷，并且毫不费力。事实上，今天应该没什么能阻止我们向小型和中型屏幕的原生应用的标准看齐。
为了达到这种效果，我们需要摆脱那种让我们有了今天的一页一页传送的古老方式，最终我们兴奋地全面重构了前端代码。
Leland Richardson最近在React大会上发表关于React Native在一个现存的，高流量原生应用的棕色地带。这篇文章会说明我们如何在在web上进行一个类似的彻底的升级。如果你也面临着这样的问题，希望这篇文章对你有用。
放弃Rails
在为我们小组里的所有响应式web应用粉丝开一场户外烧烤之前，我们需要从Rails中解脱出来(至少是我们在Airbnb上用Rails传递独立页面的方式)
不幸的是，就在几个月前我们的搜索页面还包含一些非常古老的代码...就像指环王中说的，在你危险的时候触摸它，这般古老。一个有趣的事实：有一次我用一个简单的React组件替代Rails显示层支持的Handlebars的模板，突然在页面的很多不想关的部分出现了错误，甚至在API的返回结果里面也出错了。事实证明，显示层改变了后端Rails模型，这些模型一直在影响下游数据，甚至在UI没有被渲染的时候。
简言之，在这个项目上，我们就像印第安纳琼斯一样用自己的宝物交换了一袋沙子，突然庙塌了，我们落下的石块中跑出来。
第一步：标准化API数据
当Rails在服务器端渲染页面的时候，你可以用任何你喜欢的方式把数据扔给服务器端的React组件。控制器，助手，显示层能生成任何形式的数据，甚至当你把页面的一部分转移到React时，每个组件都能处理它要求的任何数据。
但是一旦你投入到渲染客户端的流程时，你需要动态获取你事先决定好数据类型的数据。我们将来可能用GraphQL类似的东西解决这个问题，但是现在暂且把它放到一边吧，因为这件事和重构代码没太大关系。然而，我们选择向API“v2”(version 2)标准看齐，所以我们需要我们所有的组件都能处理v2范式的数据。
如果你发现自己和我们情况类似并且是一个大型的应用程序，你可能发现我们所做的迁移现有的服务器端数据管道的计划是整体工作中较为简单的部分。跨过Rails的简单步骤就是渲染一个React组件，确保数据输入时API所规定的类型。你可以进一步使用客户端的React PropTypes来验证数据类型是否和API v2一致。
对我们来说棘手的问题是和那些参与客户预定流程的团队协作：商业旅游，成长，假期出租项目；中国和印度市场团队，灾难恢复...等等不能一一列举的团队，我们需要重新告诉这些人，即使直接把("明白了，这仅仅是一种实验，但是...")这样的数据直接传递给组件在技术上是可行的，但是所有的数据都要经过API这一层。
第二步：非API化的数据：配置，实验，短语，L10n, I18n...
有一类单独的数据和我们设想的API化的数据不同，包括应用配置，用户实验任务，国际化，本地化等等相似的问题。这些年来Airbnb已经建立了一套难以置信的工具来支持这些功能，但是把这些数据传送到前端的机制就不那么令人愉快了（也可能当时写代码的时候就已经让人痛不欲生了，但是脚下的大地还没有颤动，所以糊弄过去了）
未完待续