面向小白开发者的 Meteor

今天的对象是小白开发者,明天则是专业开发者

Meteor 的使命是帮助更多的人编写出更好的软件,它所有的设计思想都围绕于这一点。允许只懂得 JavaScript 语法的小白开发者走上一条清晰之路,从入门教程到开发文档,从安装过程到部署运行,从快速创建原型到实际运营的安全保证,这一步步要么是完全自动化的,要么是循序渐进的,不需要为了第一个项目提前储备知识,且在项目编写过程中积累的经验教训完全可以迁移至下一个项目。这种毫无压力的学习过程,是曾经作为小白开发者的我的亲身感受。

1. 一键安装

这是进入 Meteor 时空的第一次神奇时刻,小白开发者也许不会有多大感受,反倒是那些资深开发者会认为,『这怎么可能』、『有点过于方便了吧』、『你让我这个爱折腾的人情何以堪』。

安装过程就一步,在系统终端界面输入 curl https://install.meteor.com/ | sh 后回车,接下来就完全自动化了。

install-meteor

上图就是整个安装过程,安装完成后,它还把创建项目的方式告诉你,让使用者立即尝试把玩。

2. 两个非常不安全的包裹

每次用 Meteor 创建新项目时,它都会默认自带两个非常不安全的包裹,一个叫 insecure,官方描述为 Allow all DB writes from clients (for prototyping);另一个叫 autopublish,官方描述为 Publish all data to the clients (for prototyping).

它俩的作用是让访问者有权限在浏览器中调用数据库并对其进行操作,方便初期的演示和快速迭代。不过,在正式上传至服务器前,这两个包裹是应该被删除掉的,使 publish 不再 auto,让操作权限变得 secure. 这时就要自己确定 Pub/Sub 关系,以及编写 Methods 通过服务器验证权限后再对数据库进行操作。

Meteor 团队为什么要为每个新项目默认加上这两个不安全因素呢,正是因为它的设计思想围绕于允许更多的人上手使用。即便不知道如何发布和订阅数据库,不清楚如何安全地操控数据库,照样不影响用最小知识量起步上路。也正因此,才能快速高效地实现原型和演示,这也是 Meteor 的第二次神奇时刻——不过它是有代价的。

3. 松散的代码组织结构

怎么个松散法呢,放在 /client 文件夹下的代码是只运行在浏览器端的,放在 /server 文件夹下的代码是只运行在服务器端的,放在其他文件夹下的代码则同时运行于浏览器和服务器。这是最基本的规则,还有一些规则来判别文件加载的先后顺序,其优势是前期易于理解,劣势为后期有可能造成混乱。Meteor 团队为什么要这样设计呢?我猜哈,原因和前面相同,允许使用者以最小知识量起步上路。Dropbox 使用传统的文件管理界面,是为了吸引并占领熟悉使用文件夹整理文件的普通用户,其道理是相通的。

不过 Meteor 也绝不停留于此,明天我会向大家介绍它还有更加专业、严谨的代码组织结构

4. 一键部署

当下介绍这一点还是比较尴尬的,因为它曾是 Meteor 的第三次神奇时刻。以前只要一个命令,meteor deploy app-name.meteor.com 就能自动打包、上传并完成部署、运行,然后就能获得一个允许全球访问的演示地址,且是免费的。现在基于成本的考虑——包括运营与维护成本——Meteor 团队将这一免费服务关闭了。

取而代之的是它们的盈利服务——Galaxy——按秒计费,最基础的价格是 0.035 美元/小时,可以随时扩容,价格也是翻倍往上走。他们的服务器基础设施用的是 Amazon.com, Inc. 的 AWS 服务,目前正打算往欧洲和亚洲开设服务,不过我猜短期内满足不了中国特色——因为没有牌照。它的神奇之处正是继承了原先免费服务的一键部署,并且有丰富的实时后台数据分析。上个月,我个人把项目从 DigitalOcean 迁移至 Galaxy,怎么说呢,俩字,省心。

我再往深了猜哈,Meteor 团队早晚会提供类似私有云部署的服务,这样国内团队就可以用自己的服务器来使用 Galaxy 服务了。

5. Blaze (类似 React, Angular 的前端框架)

让我们将视角回到 2012 年,那时 Angular 称霸,React 尚未公开,Blaze 的前世 Spark 随 Meteor 出生。四年时间,Angular 继续占领传统市场,已显疲态,其第二代尚未建立优势地位;React 异军突起,已然成为新项目的前端标配,同时,它允许传统架构逐步转变过来,这一点大大提升了决策者的信心;Spark 和新一代 Blaze 只能用于 Meteor 项目,这是它的致命伤,在整个市场几乎不存在占有率。

以上为大局。Meteor 团队并不固执,它的核心竞争力是开发者体验,使命是帮助更多的人写出更好的软件。因此在8个月前发布的 Meteor 1.2 版本中官方同时支持 Blaze, React 和 Angular。也就是说,它们仨,在 Meteor 的进化过程中,都是地位平等的一等公民。

就我个人而言,我已全面从 Blaze 转为 React。虽然它们各有优势,但后者更适于程序员思维。值得一提的是,在同一个项目中,Blaze 和 React 是可以混用的,也就是说,允许并存,维护人员可以慢慢逐步转变。

回到主题,我为什么要提 Blaze 呢?因为它再一次体现了 Meteor 团队的设计思想——允许使用者以最小知识量起步上路。只不过后起之秀 React 将这一思想贯彻得更彻底、更开放、更兼容。Blaze 败了,实属正常。

6. Meteor 指南 (guide.meteor.com)

这个指南太重要了,它把过去人们使用 Meteor 的经验教训筛选、总结下来,供新人阅读、学习。它由官方维护,接受社区贡献。使用 Meteor 的路子有很多,Mantra 是一种,这个指南是另一种——官方的。我建议先按官方提供的路子走起,我自己也是这么做的。

7. 丰富的包裹和组件

Meteor 具备超强的扩展能力,为此还组建了自己的生态,这事儿得分两面来看。Meteor 团队希望先提供一个拥有最好开发者体验的包裹扩展方式,即 Atmosphere packages. 其允许单个包裹分别向前后端部署代码,同时可以和内部包裹进行协作、整合,这个 npm 还办不到,Meteor 团队只能自己造轮子。另一面,npm 这一生态环境具有太多的价值,脱离掉它会让开发者尤其是大型项目开发者失去信心,Meteor 看到了这一点,决定拥抱生态,于 Meteor 1.3 版本正式以官方手段支持导入 npm 的所有包裹。这对专业开发者来说可谓意义深远。

看出其中的规律了吗,当市场上没有符合自身设计理念的轮子时,自己造,以此允许使用者以最小知识量起步上路。然后再支持市场上最重要、流行的部件,且能够并行生存。一句话比喻,先开辟一条车道,你可以在上面稳稳直行,再并入多条市场上存在的优质车道,你有能力、有更多需求时,随时变道。