一周前 rethinkdb 终于正式正式发布了 horizon，一套如前所述 rethinkdb 的前台应用：它让你只须要做一些基本的安全配置和 validation，就能在后端操作形式 rethinkdb。是不是听出Marcillac？它比较像 meteor 采用的 minimongo，或者说实现的形式有些不同：minimongo 是 mongodb API 的两个开集；而 horizon 操作形式资料库的 API 不但是 ReQL（rethinkdb 的 query language，等效 SQL）的开集，API 的USB也完全改写，以期于更好地控制后端对资料库的操作形式。
上述这段文字的统计数据量略大，建议大家往上看之前：
没母汤氏 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 的软件系统，尤其在大规模mammalian情景下（如 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) 个性化，所就须要开始囤积更多的后端技师了。
