https://mp.weixin.qq.com/s?__biz=MzA3NDM0ODQwMw==&mid=2649827302&idx=1&sn=c896887381cfe538628588c4c7bcfd16&scene=0&key=f5c31ae61525f82eda16f02af5ce0fc6d7063616421b964248ccd63a90da562aa1ab98189b880b8884fb03787d3ac752&ascene=0&uin=MjY0Njk0Mjk1&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.11.2+build(15C50)&version=11020201&pass_ticket=wriLNVUWFnoD%2Bg%2FobN92b1phj20gRaIN%2FjR%2B%2BgLSQw4%3D
怕找不到了，暂存下
两周前 rethinkdb 终于正式发布了 horizon，一套基于 rethinkdb 的后台应用：它让你只需要做一些基本的安全配置和 validation，就可以在前端操作 rethinkdb。是不是听起来耳熟？它比较像 meteor 使用的 minimongo，只不过实现的方式有些不同：minimongo 是 mongodb API 的一个子集；而 horizon 操作数据库的 API 不但是 ReQL（rethinkdb 的 query language，类比 SQL）的子集，API 的接口也完全重写，以便于更好地控制前端对数据库的操作。
上述这段文字的信息量略大，建议大家往下看之前：
-
没听过 meteor 的，去 meteor 的官网上看看，生成几个样例中的项目运行起来感受一下；
-
没听过 rethinkdb，可以去官网了解一下它和 mongodb 的区别，然后
brew install rethinkdb，登上 web admin，体验一下 ReQL。
多说两句 rethinkdb。rethinkdb 一大亮眼特性是 changefeed。它能够把数据库中某个查询结果集的改变 publish 出来，供其他人 subscribe。这个特性对 realtime collaboration 的 app 来说非常有用。我们看一个在线的项目管理系统，如果用户 A 修改了某个项目 x，我们想让所有和项目 x 相关的用户的界面立刻得到实时更新，该怎么做？
如果使用传统的解决方案，我们需要客户端和服务器保持 websocket 连接，A 的修改行为在服务端成功后要发布一条 message 到 message queue，并路由到合适的 worker 进行处理；worker 从 queue 里拿到 message 后，将其 broadcast 到所有相关的 websocket，然后客户端的 websocket 收到数据后再分发给合适的函数处理，从而更新界面。
而 rethinkdb 在数据库层面将这个方案的后台部分都打包进了 changefeed。你只要定义好你对哪个查询的 changefeed 感兴趣，当满足这个查询的数据被修改（创建/删除）时，changefeed 会源源不断地推送出来修改，供你使用。
有了 changefeed，提供实时功能的后端的逻辑一下子变得简单起来，可以减少很多中间环节 —— 别小看就多了个 message queue 和对应的 worker，做成产品意味着相当多的精力和投入。虽然使用 changefeed 的方式并不能取代传统的使用 message queue 的解决方案，尤其在大规模并发场景下（如 slack）changefeed 的 performance 会遇到严重的瓶颈，但对于 MVP，或者处在快速发展中的小产品，这是一个优雅的，对工程师来说高效的解决方案。
回到 horizon 本身。horizon 在 rethinkdb 基础上，进一步把对数据的不管是基础的还是复杂的 CRUD 的操作都封装起来，暴露给前端，使得一个产品几乎不需要后端的干预就能跑起来，支撑产品的头数十万的用户。horizon 并非第一个这么做的人，被 facebook 收购的 parse，被 google 收购的 firebase，也走的是这个路数，而开源项目里，也有 postgREST 这样通过巧妙地设计把数据库暴露成 API 供前端调用的工具。
这种近两年来渐渐发展起来的趋势是：后端傻瓜化。
为了搞明白为什么现在大家热衷于「后端傻瓜化」，我们看一个产品初期主要需要什么功能：
-
authentication：用户身份的认证和鉴别（并非必须）
-
用户数据的存取和处理
-
内容的展示
-
内容的存取，处理
-
如果上述的一切都能实时发生，那最好不过（并非必须）
这里的内容，而是指一切和产品相关，要展示给用户的数据。比如一篇篇文字，一张张图片，或者一段段视频，或者一个个 SKU，都是内容的范畴。
内容的展示是面向用户的，是产品暴露给用户的部分；而内容的存取和处理是面向内容团队的，是冰山下面的东西。比如，一个 CMS（Content Management System）。
抛开产品是否 realtime 不说，单单实现这些功能，后端就需要一套 API 处理包括登陆在内的所有数据相关的事情，同时还需兼顾服务器的维护；而前端则需要至少做一个面向用户的 app（比如移动端的 app），还要一个面向内容团队的 CMS UI。如果要实现 realtime，那么难度又要增大一些。
如果你看过我之前写的 Rest API 系列，把 API 做好并不是件容易的事情。然而 API 这个东西，就像 postgREST 的作者说的那样，重复劳动太多，净在重新造轮子了，或者是重新组装汽车了：数据的验证（validation），用户身份的验证（authentication），用户授权（authorization），数据的持久化（persistence），以及 API 本身的 CRUD 功能。
而初创公司在 MVP 阶段，很难同时把这些事情做好。大家的选择基本是：凑合完成一个中不溜的后端，然后把发力点集中在用户可见的前端产品上。这是一个被人月神话诅咒的，不得已的折衷方案 —— 它可以让 MVP 尽快到达用户，让市场检验其成色 —— 但同时为未来的发展埋下了严重的隐患：之前凑合出来的部分，日后都要花费数倍的精力重构，或者重写。应了那句老话：出来混，迟早要还的。
这就是后端傻瓜化的产品的意义：它帮你使用几乎为零的人力成本，打造出一个可用的，安全的，有足够容量的后端系统。产品只消集成其 SDK，做出合适的设置，然后再调上几个现成的 API，就可以不用太理后端的事务。
这是一个趋势，相信以后越来越多的工具会涌现出来。可惜 firebase 这样优秀的产品，在国内无法使用（或者可以使用但是大家都不敢使用 —— 万一哪天就连不上了呢？），所以我们只能依赖像 horizon，meteor 和开源了的 Parse 这样的工具。
这个趋势放在早期技术团队的搭建上，就是一个什么都懂一点的 CTO，配上产品覆盖的平台下的优秀前端工程师。
嗯，就这样。当然，后端工程师依然重要，但是他们更大的舞台在稍微大一些的，找到了 product market fit 的团队中，这个时候，产品渐渐需要：1) 更复杂的 API 和后端处理能力（不是简单的数据库处理）；2) 数据追踪和分析 3) A/B testing 4) 个性化，所就需要开始囤积更多的后端工程师了。