首页 > 业界 > 后端傻瓜化?
2016
06-04

后端傻瓜化?

  两周前 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) 个性化,所就需要开始囤积更多的后端工程师了。

最后编辑:
作者:同创卓越
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。