广义的Web全栈，一般包含后端开发、前端开发、界面设计、产品设计、数据库、各种移动客户端开发等等，狭义的Web全栈则至少包含后端开发、前端开发、数据库。全栈的难度在于要求你掌握前后端的多种技能、可能要学会多种语言，比如大家都很典型的全栈概念LAMP（Linux+Apache+Mysql/MariaDB+PHP/Python/Perl），前端要用Javascript自不必说，后端或用PHP、或用Python/Perl，数据库你还得会SQL，要想一个人掌握这么多技术和语言，还是颇有些难度的，即使掌握了，在实际开发中，你的脑袋还要在各种不同语言之间来回切换，既增加了脑力负担，有提升了出错机率，实在是一件让人郁闷😒 的事情。
当然，学习正统的MEAN开发，你还是要分别去学习MongoDB、Express、Angular和Node.JS的，有没有更加简单（偷懒）的方式呢，想什么呢 🔨 ! 答案是：还真的有 —— 那就是 Meteor 🌠 （Web界的流星），按照《Meteor实战》的说法，Meteor仍然是基于MEAN栈的，或者说是属于泛MEAN阵营的（即泛指那些运行于Node.js之上并使用NoSQL数据库的任何框架。MEAN栈架构图见图2）。只是Meteor建构了一个捆绑的更为紧密的生态系统，而不仅仅是服务器进程和库（框架）的组合。
图2 MEAN栈架构图 图3 Meteor超跑简单地说，Meteor是完全使用JavaScript创建富Web应用程序的开源平台。它在同一个框架下捆绑并提供所有必需的组件。它由以下几部分组成：Node.js、MongoDB、实际的应用程序代码，以及一个强大的CLI工具。
本书的第二部分（3-10章）进一步通过实战性的例子详细介绍了Meteor的主要组成部分（见图4）。
图4 Meteor主要构成图第5章介绍了Meteor的重头之一——响应式编程，利用Meteor数据库无处不在的原则，并使用只存在于客户端的本地集合。这样做的好处在于，你对数据／表单的更改变化在界面上直接反应出来，不用等到数据提交到后台再被取回前端再渲染，实际上就消除了等待数据往返后端的时间，在用户体验上自然能得到更好的效果。
生产环境中的Web应用肯定离不开用户注册和登录，以及认证（authentication）和授权（authorization），并且要更细粒度的方式来定义用户权限，这些工作如果是自己开发，那都是很繁琐的事情，而且安全性 🔐 还是个问题。而Meteor已经帮你把这件事给做好了，你几乎不需要再写任何代码。当然，你也可以不自建用户名和密码系统。使用常见的社交账户登录到你的应用可以降低注册的门槛，这种方式我们称为OAuth（Open Authorization），Meteor集成了诸如微博、脸书、GitHub、推特、谷歌等账号登录的API，你只要敲下“meteor add accounts-facebook”这样类型的指令就够了。
结合用户认证和授权，Meteor就可以轻松的根据用户权限和系统配置来实现用户数据的发布和订阅，比如通过文档字段（比如用户/所有者ID）来安全地限制所发布的数据，或者确保客户端提供的所有数据在使用前都进行了验证。
第8章介绍的是Meteor的路由、第9章是Meteor的包管理，这些内容在各种前端框架中都比较常见，所以不再赘述。
总结，Meteor的主要优点如下：
1、容易学习，与正统MEAN栈相比，新开发人员不必对松耦合的前端库和后端框架进行深入地研究，就可以实现一些应用。对JavaScript有些基本的了解就足够开始。
2、大部分应用可以在客户端上运行，好处是：服务器的负载会较小，用户界面的响应很快，用户体验比较好。
3、代码可重用，由于Meteor的同构（Javascript）性质，同样的代码可以在浏览器中、服务器上甚至是移动设备上运行。
4、强大的命令行工具，Meteor提供了开箱即用软件包管理和构建管理工具，覆盖了整个构建过程，从收集和编译源文件到文件精简、源映射、解决依赖关系等等，让你把心思用在业务逻辑上。
如果你需要一个快速的应用原型开发工具 🔧 ，那么Meteor一定是一个优秀的选择 ☑️ 。