作者：郑美赞,简传挺
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Serverless架构：无服务器单页应用开发试读：
前言
我做了几年单页Web应用，一直希望能摆脱应用服务器施加的限制，现在愿望终于实现了。Amazon（还会有更多的其他公司）开发出的技术让无服务器架构（serverless，在本书中简称为“无服”）成为可能，消除了很多构建和扩展Web应用的风险和成本。这个创意是如此令人叹服，如此具有变革意义，以至于我必须为它写一本书。
这本书是为那些希望在Web上构建一些东西的人而写的。有的人想搭建一个应用——一个他们认为将会是下一个惊世之作的东西。有的人只是刚着手Web开发，从未构建过任何类型的应用——不管是影响世界的还是其他什么样的。有的人则是已经用Java、Ruby on Rails或者Node.js构建过许多基于Model-View-Controller应用的资深Web开发者。随着这个无服技术的兴起，我希望能分享所学的一切，真心希望有人能够用它做出一些了不起的东西。
在前言中，你将了解本书的主题以及能用这些技术来实现些什么。
指导原则
写这本书时我脑子里有几条指导原则。这些原则的目的是让本书内容具有针对性、易理解，不说废话。这里把它们列出来，帮助你了解我是如何写这本书的以及更好地理解本书的相关背景。
有些原则可能是有争议的，其中一些甚至与构建Web应用的主流思想相左。但是，这些原则将帮助你深入理解这个主题。与其波澜不惊，存在争议会更好。
使用Web标准和熟悉的工具
在这本书中，你将使用一小部分精选的工具来构建一个单页Web应用。在本书的某些节点上，你将会实现其他工具已有的功能，这些工具是我有意不在应用中引入的。你可能会好奇，既然它们提供了所需的功能，为什么我们不用呢？
阅读本书实际上是一个学习的过程。当学习知识时，使用熟悉的工具是有帮助的。不然，花在学习工具上的时间比花在学习技术上的还要多。我不希望对一个框架或者库的选择让我们偏离本书主题。这本书是关于无服Web应用，而不是关于框架或者类库的。为了保持未知性，我们将会使用那些Web开发者熟悉的工具（例如jQuery）、Web标准和Web服务，来实现一个无服设计。
这本书是关于Web服务，而不是Web框架的。
有可能读完这本书，你将会接触到一种客户端Web框架，比如React或者Angular，来构建你自己的Web应用。这些工具近些年在Web开发者社区获得了很多关注，我希望能看到很多使用它们的成功项目。在本书中学到的所有知识与你希望使用这些框架做的事情都是兼容的。它们是互为补充而不是相互冲突的关系。
使用函数式JavaScript
本书中你将不会创建JavaScript的任何类。创建类结构来解决问题对于一些具有富类型和面向对象类型系统的语言是合理的，但JavaScript不是这样的语言。相反，我们将使用更易于理解的函数式风格。
这意味着你将不会遭遇this关键字的范围问题。你将会避免原型和继承的共同使用。你不会使用new关键字和专门设计的函数来创建对象；相反，你将会使用一个字面意义的对象来创建它们：{}。
你可以自己决定这是否就是你希望采纳的风格。因为这种方式拥有一些实际、立竿见影的好处，最后许多软件设计决策实际上都会偏向这种风格。代码终究应该首先是给人写的，然后才是计算机。只要它可执行，对于计算机而言代码看起来如何无所谓。
避免无用功
做项目时，我的目标一直都是：持续交付有改进的结果，只要这个改进是朝着环境需要的方向在进行。实现这个目标意味着要避免任何能造成交付率被消磨的事情，比如剃牦牛（yak shaving）。
如果你对“剃牦牛”这个词不熟悉的话，想象一下你想要给朋友买一件毛衣。你走进一家商店却发现没有毛衣卖。幸运的是，那里的另一位客户知道街角有一个很好的裁缝，他可能可以为你做一件。所以你到了裁缝那儿，他有一个非常好看的毛衣图案和一台能编织这个图案的机器，但毛线供应商今天还没送货。所以你跑到供应商那儿……
然后这个过程一直继续，直到你发现自己在西藏的一片牧场上剃耗牛毛来编毛线。“我怎么来这里了？”你可能会问自己，“我所需要的只是一件毛衣。”当一系列看起来相关和必要的任务让你从真实目标上偏离时，你就是在剃耗牛。幸运的是，剃耗牛的解决办法很简单，就是意识到你自己一直在剃耗牛，然后转而买一顶帽子。
我希望你在阅读本书时不要剃耗牛。这就是为什么我用了一个预备好的工作空间以及尽可能少的工具的原因。你应该把时间花在学习上，而不是安装软件、配置和排错上。
通过测试来加快进度
你有没有曾经害怕过修改甚至只是修改一点点代码？也许你当时不确定应该做什么或者为什么应该做这个。“首先，不作恶”对程序员和医生而言均适用。这种情况会让你感觉进退两难。
设想你做这些改动时，有一位可信的同事——这类系统的专家——就坐在你身边。如果你引入任何缺陷到系统中，他就会拦住你，清楚而明确地告诉你为什么这个改动是个坏主意。如果你有这样可信的同事，是否还会进退两难？
不确定性拖慢了我们的脚本，并且限制了解决方案的范围。为了快速搭建一个软件，你必须有自信。为了获得这份自信，你可以为自己创造一个自动化专家——它了解系统的所有细节，知道系统如何运转以及为什么这样运转。这位专家和系统相辅相成，随着它的改变而改变，互相影响。这个专家就是你编写一套测试，它们快到能持续运行，每秒能运行成百上千的测试，而且每次在你对代码进行修改之后都是如此。
一旦你有了测试套件，就拥有了新选择。而当你不再害怕修改代码时，就可以按照自己的设想来设计应用，而不是试图让它在一开始就要“正确”。这意味着你可以随着形势的变化快速适应这个世界，而不是试图预测你可能需要和不需要什么。你可以基于当下的信息而不是靠猜来做决策，应用就会自然而然地变成它应该的那个样子。
在本书中，你将使用测试驱动开发（TDD）技术来编写应用和它的测试。了解如何用测试来构建软件是一项技能，要获得它的益处，就必须真正地使用它。我在本书中引入TDD的目的不仅是向你展示如何测试Web应用的特定功能，还想证明用它来测试典型Web应用有多简单，如果你知道如何实现的话。
在实践TDD的过程中，有一个三步循环，经常描述为红—绿—重构。首先写一个测试，检查应用尚不具备的功能。如果测试如你预期的那样失败了，就可以相信它是在测试你希望加到应用上的功能。现在这些测试是红色的。一旦有一个失败的测试，添加几条最简单的代码来让这个测试通过，通常几行代码即可。现在这些测试是绿色的。
通过测试为应用添加一些功能后，就该后退一步，让自己看得更全面一些。是否在实现中引入了一些重复代码？所有的变量和函数是否都有描述性的准确名字？是否还有更简单的方式？考虑这些事情，然后开始重构。重构是在不改变功能的情况下修改代码。你之前编写的测试会告诉你是否改变了功能，所以只能在这些测试都通过时重构，这一点很重要。有了它们作为你的安全防护网，可以在开始下一步测试之前清理完所有代码的问题。
TDD用得越多，你的进展就会越快，从中获得的价值就越多。通过一遍又一遍地重复“红—绿—重构”过程，你将学会如何渐进式地构建一个设计合理、测试充分的应用。这样你不仅对自己的应用有信心，而且对它进行持续的修改也更容易。
边做边学
本书是一本教程，所以你可以跟着书中的引导边做边学。通过这本书，你将构建一个无服单页Web应用。本书的目的是用具体的方式解释无服架构的原理。本书的成果是一个可运行的应用，所以你大可以放心，书中的技术就像广告中说的那样有用。
采用这种方式意味着篇幅有限，我对有些知识点不可能讲得很深入。因此，我在每章中安排了一节“下一步”来提供一些主题，如果你希望了解更多，可以查找相关的资料。
从预备好的工作空间开始
为了让你能快速上手，我提供了一个预备好的工作空间（prepared workspace），里面包括了起步需要的所有东西，并且不需要太多时间来设置。这就好比你在画一幅艺术品，我已经为你准备好颜料、画架和画布。你要做的就是创作。
为了能使用这个预备好的工作空间，你需要一台兼容Bash shell的计算机来使用工作空间里面的脚本和工具。可以是OS X、任何*nix版本或者FreeBSD。如果你安装了Cygwin，用Windows可能也行。你还需要一个带开发者控制台的Web浏览器。本书的大部分例子中使用的是Google Chrome，但大多数情况下Firefox也能提供了类似的功能。
如何阅读本书
阅读一本书可以有很多种方式，不仅是从头到尾的那种。至于如何阅读本书，取决于你想要获得什么。下面列出的是读本书的一些常见理由，以及我对于如何使用这本书来实现这些目标的建议。
目标1：理解无服和传统单页应用的优劣需要做什么
1.阅读第1章的前3节理解两种方式的优劣。
2.略读第1章剩下的部分和第2～3章。
3.通读第4～8章，尽可能跟着教程实现应用。
如果你是一个有经验的Web开发者，搭建过单页Web应用，希望了解更多有关无服Web应用的知识，你可能不需要看前3章的所有内容。这些章节展示了搭建单页Web应用的vanilla.js方式。其意图是阐述一个单页Web应用的基础模块。我尽量定义哪些部分是必需的，并提供一些可供参考的基础实现。如果你没有给Web应用编写过很多测试，可以在第2章中实现一些测试例子来学习一些新技能。
读完第1章的前3节，你会希望集中精力细读第4～8章。我建议你搭建一个简单Web应用，或者至少一个原型，这样你可以在后面的章节中自己尝试这些技术。通过实验可以学到很多。
目标2：搭建你的第一个单页应用需要做什么
1.在开始前，先读一读书中列出的必要的辅助阅读材料。
2.从头到尾读完本书所有的章节，如果有必要，附录也要看。
如果你是第一次搭建Web应用，你会希望阅读整本书，从头到尾读一遍。另外，你可能也想跟上基础Web技术的脚步，包含HTML、CSS和JavaScript，可以查阅下面的免费资源。等理解了这些主题，再来深入读本书。
免费资源
Learn to Code HTML & CSS [How14]，Shay Howe著
Eloquent JavaScript [Hav14]，Marijin Haverbeke著
目标：使用你喜欢的Web框架搭建一个无服应用需要做什么
1.通读第1章。
2.用你喜欢的Web框架实现第2章和第3章的测试与功能。
3.通读第4～8章。
正如前面说的那样，我不希望把这本书的重点放在Web框架上，但还是可以使用它们来搭建无服单页应用。如果你对单页应用的基本元素很熟悉，并且靠客户端Web框架来提供这些功能，可以用喜欢的框架轻松重建我们在第2章和第3章实现的功能。一旦有了这个作为基础，应该可以遵照本书余下的部分，用这个框架实现整个应用。
目标4：创建一个最小可行产品（Minimum Viable Product，MVP）需要做什么
1.阅读第1章的前3节，理解无服开发与传统开发方式的优劣。
2.阅读第8章来了解用这种方式构建一个MVP的成本。
3.如果这个方式看起来行得通，阅读剩余的所有章节（如果有需要的话，包括附录）。
3.使用预备好的工作空间作为搭建MVP的起点。
当启动一个新产品或者一项新业务时，首要的挑战是搞清楚市场想要什么以及它愿意为什么付钱。许多人称之为产品/市场匹配（product/market fit），这是构建一个成功产品或者服务的关键。
找到产品/市场匹配的一个有效方式是先做出一个产品并试着销售。验证市场的需求和你通过销售或市场渠道连接这些客户的能力，这是你应该尽快跨过的关键门坎。当然，你可能又没那么多时间和资金来搭建一个完整的应用，所以一个替代方案是搭建一个MVP来验证产品的核心价值。
无服单页应用是尝试新主意、探索可能的新市场或者创建MVP的好方式。搭建这类应用来替代传统Web应用或者原生应用，意味着你可以更快接触到客户。你可以在若干小时内搭建一个初始版本并在几秒内部署。这些应用可以立即更新，轻松地被拆分测试，可以提供详细的使用指标，帮助你理解客户想要的是什么。
除了运行起来不贵、快速构建以及几乎所有用户都能访问之外，无服单页应用可以“无限”（正如Amazon宣传的那样）扩展，这样如果你的产品在市场上有旺盛的需求，你就可以满足这样的需求以及留住用户。
在线资源
你可以在Progmatic Bookshelf官网找到这本书中的应用以及代码。你还能在上面看到社区论坛和提交勘误的表单，报告问题或者为未来的版本提供建议。
你可以在我的Github.com账号（benrady）下找到预备好的工作空间。如果你还没有Github账号，那就新建一个，并且fork我的代码库。想知道更多操作细节，可以阅读第1章的内容。Ben Radybenrady@gmail.com
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
·提交勘误：您对书中内容的修改意见可在提交勘误 处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
·交流互动：在页面下方读者评论 处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http://www.broadview.com.cn/31736第1章从简单开始
如果你曾经想过“应该有一个实现这种功能的应用”，并憧憬有谁能够为你开发一个就好了，现在我们有一个好消息，那个人找到了，就是你自己。
Web应用可以是非常强大、高效和易扩展的，但却不应该是复杂的。简单就是Web应用的一大优势。你可以利用这种优势来搭建自己的解决方案，实现自己的创意。一旦了解所有模块是如何搭建到一起的，你就能开发出想要的应用了。
本书是一本实用教程，将会演示一种无服务器的方案来搭建Web应用。使用这个方案，大部分运维方面的问题就不需要你自己操心了，而且也省去运行服务器的费用。你能集中时间和精力开发想要的应用，而让其他人去考虑业务发展带来的应用上线、配置、升级、扩展服务器等问题。使用多层Web框架、自动生成的代码或者拷贝模板，这些方法并不会带来这样的好处。等我们一起学完本书，你就会知道如何通过移除部分代码和消除中间层来交付更好的应用。
为了能够快速演示开发过程，我们将使用一个预设好的工作空间，里面加载了搭建完整Web应用必需的所有模块。首先，我们会完成一个单页应用，用JavaScript、HTML和CSS代码来实现原来在服务器端实现的逻辑。我们将根据Web标准，深入挖掘单页Web应用的必要功能，从零开始搭建，从而了解它们的运行机制，保证这种设计能符合我们应用的要求。当仅凭Web标准不能完全实现需求时，我们会使用jQuery来填补差距。最后，我们会使用测试优先的方法来渐进式开发，以保证单页应用的可测试性。
为了降低中间层成本并确保我们的应用能供上百万的用户使用，我们使用Amazon Web Services（AWS）作为无服应用的后端。你将看到如何使用高可用、高可扩展、更便宜、更易维护的云服务来替换掉传统Web应用的服务器、数据库和负载均衡器。我们将讨论在开发此类应用时会碰到的一些安全性问题，并会介绍随着应用业务的扩展可能会用到的其他技术和工具。
我希望这本书能够让你看到新的可能性。以前非常费时费钱的应用开发或许能变成一个人在一两天内就可以完成的事情。随着技术进步和个人能力的提升，更多的梦想将会实现。一旦理解了这些技术的发展，你就会发现从前因为太难而几乎无法实现的目标，现在可以借由新途径来达成。读完本书，你将学会将创意变成真实应用所需的技能。无服Web应用
在传统Web应用中，服务器是系统不可缺少的组成部分。尽管有时候服务器的前面还有负载均衡器或者专用Web服务器，但完成大部分工作的还是应用服务器。它完成一个应用所有的必要功能，包括存储用户数据、进行安全认证、控制流程等。应用的页面大部分仅仅只是为后端提供界面而已，尽管也会涉及一些控制导航的功能。使用这种许多人称之为多层架构的传统方式，系统一般会由浏览器、应用服务器和多个后端服务构成（见下图）。
使用无服的方式，可以移除所有这些层次架构，达到更直接的实现。与其仅仅把网页客户端当作应用服务器的界面展示，不如构建一个单页Web应用在浏览器中实现应用逻辑。这意味着你只需要一个简单的静态网页服务器，所有的交互都只不过是应用内容的传输而已，浏览器就像是一个应用容器。这样，最终的设计就是移除传统Web应用架构中所有的中间层次，允许浏览器直接连接到它所需要的服务上。多层结构的设计
使用Facebook、Google和Twitter之类的OAuth 2.0身份认证服务商提供的服务，无须保存用户密码就可以创建用户身份。如果要存储数据，你可以在浏览器端直接使用Amazon DynamoDB之类的服务。在浏览器中无法执行的函数都可以使用Amazon Lambda微服务或者其他专门的Web服务来处理。除了能够简化架构，这种切换到Web服务作为后端的方式，还能让应用获得这些服务与生俱来的可用性和可扩展性优势。
你可能会好奇到底发生了什么，使这种方式成为可能。为什么现在在一个Web应用中，中间层的应用服务器变得可有可无呢？答案是，自从2015年以来，类似Amazon这样的云服务提供商开始对外提供服务的API，这使得无服务器的方式成为可能，Amazon本身也为如何使用他们的工具和基础设施提供了最好的示范。
基于Web标准搭建一个单页Web应用，而不是使用服务器端Web框架来完成，我们可以快速应用一些新兴技术。例如，我们不再需要将应用的数据模型绑定到任何一个对象层级或者数据同步机制上，因而能更方便地集成不同服务。既然我们所有的工作都倚赖于Web，就不必拘泥于以前搭建Web应用的成见，可以用目前最新的技术来搭建应用（见下图）。无服应用的设计无服设计的好处
如果你在寻找一种快速搭建低成本Web应用的方法，无服Web应用很可能就是一个解决方案。不需要花费时间和精力了解传统Web应用技术栈的各个层级，采用这种方式你能更专注于实现业务功能，有人会为你操心运行维护和可扩展性的问题。接下来让我们深入探讨无服设计的好处，帮助你在考虑下一个项目中是否使用这种方式时做出更明智的决定。
零服务器
无服设计最明显的好处就是不需要维护服务器（不管是物理的还是虚拟的）。你不需要担心打安全补丁、监控CPU和内存使用情况、回滚日志、磁盘空间不足或者其他在维护自有服务器时经常碰到的运维问题。和大多数平台即服务（PaaS）方式一样，无服设计能让你专注于应用开发，而无须担心基础设施的问题。
易扩展
这种设计方式的另一大好处是，你可以依靠云服务供应商来扩展自己的应用。在做水平扩容时，不需要忙不颠地在几个负载均衡应用服务器之间保持数据的一致性，你可以直接连接Web服务，而它们已经解决了数据一致性的问题。这意味着不管你的应用有几个用户、几百个用户，还是几十万个用户，只需要修改Amazon Web Services控制台的一些设置就可以保证完美的运行。
高可用
另外，使用这种设计能轻松实现高可用性。你不必为了升级而关闭应用服务器，或者为了实现“热”部署而扩建基础设施。不再会有服务的重启或者部署包在服务器间的拷贝。最妙的是，Amazon有一群训练有素的员工7×24小时守护着你的基础设施，一旦发现问题随时能够响应。
低成本
这些服务的成本可以非常低。使用无服的方式以及利用Amazon的免费套餐（Free Tier），一个月支付几美分就可以运行你的应用。一旦超过了免费额度，其费用经常也是随着你的用户量线性增长的（考虑费用最高的情况）。我们在这本书里构建的应用就算扩展到100万的用户，一天也只需要花费一杯咖啡的钱。（微）服务友好
这种方式可以轻松适应微服务或者其他的面向服务架构。你可以在系统中引入特定的服务以实现自定义身份认证、验证或者异步数据处理。如果有必要，你甚至可以重新引入应用服务器，渐进式地重构应用。反之，如果一开始就使用一个中间层来控制所有的安全证书，就很难切换到需要认证的Web服务上。这些应用服务器没办法像无服应用一样，在应用层管理身份信息。
代码更少
在传统Web应用里，一些操作（比如导航）在Web客户端和服务器端都需要执行，造成了代码的重复。有时候，这种重复工作并不明显，尤其当服务器代码是用不同的语言写时。而在无服应用中，应用逻辑都移到了客户端，很容易保证应用内不再有重复的代码。将应用逻辑代码放在一个位置（以及用一种语言实现）帮助我们解决了这个问题。
此外，无服的方式更便于构建和排错，因为系统的组成部分变得更少了。Web应用天生就是分布式的，也就是说，正如CAP理论所述，它们在同一个网络的节点间传递消息（一般是以请求和响应的形式），限制它们的是实现方式。
有些应用会比其他应用更分散（more distributed）。一个系统越分散，就越难排错。移除应用中的中间层能减少其分散的程度。在我们这个简单的应用中，如果一个客户端需要从一个数据库中获取数据，就会直接连接数据库，而不是通过中间层连接。这就意味着系统中的网络节点更少，也意味着如果出现问题，需要定位的地方更少。
如上所述，构建一个无服应用的理由有很多。学完本书，你就会明白为什么这种方式如此强大。了解了无服应用的这些优点，我们再来看看它有哪些限制。无服设计的限制
尽管无服架构有许多优点，但它也不是适用于所有类型的应用。为了享受这种设计带来的益处，你必须接受一系列的限制。如果你的应用不能适应这些限制，那么它很可能不是最合适的构建方式。所以在搭建应用之前，让我们一起看看这些限制。
供应商锁定
首先最大的限制就是你使用的Web服务必须支持第三方身份认证服务商，这样在云服务提供商的选择上就受到了限制。所以如果使用无服的方式，你就会依赖于第三方服务，供应商锁定也就成了一个问题。构建一个基于其他公司服务的系统，意味着这个应用的命运和供应商公司的命运绑在了一起。如果供应商公司被收购、破产或者改变商业模式，你的应用不下大力气修改就很难在其他地方运行。所以，评估服务提供商的业务目标和长期稳定性与技术选型是同样重要的。
奇怪的日志
所有运维关注的事情，比如应用日志，在你使用无服设计之后会呈现新的形态。当你把所有请求都通过一台服务器路由时，记录下所有信息以查看用户正在做什么是非常简单的事情。没有了这种中心化设计，日志的记录必须由每个支撑应用的不同Web服务来实现。这些日志格式跟大部分应用服务器日志都不同，记录的数据也很可能是你不熟悉的。我们在后面第8章的“分析S3日志”会深入探讨Web服务日志的分析。
不一样的安全模型
对于无服应用，有些常见的安全隐患不复存在，但你将会遇到一些不熟悉的新问题。比如，为了安全而验证用户数据，结果不能在浏览器中安全地实现。你需要假设有些恶意用户可能会在浏览器中劫持证书而使用该证书授权的Web服务。使用无服的方式，意味着你不能把浏览器中的应用验证逻辑和安全验证逻辑放在一起，必须分开实现。
Amazon提供的许多Web服务都能验证请求。你可以参考第5章的“数据访问和验证”一节内容利用DynamoDB来实现。然而，对于有些应用来说，很难只用Web服务提供的工具来实现充分的有效性约束。比如，在浏览器中直接编写文本时，你不可能放心地将写入的数据编码后存到数据库中，保证不会有跨站脚本攻击发生。因为攻击者不使用应用就能直接将这个数据添加到数据库。
这种情况下，你有（至少）两个选择。第一，可以假设某些用户可编辑的表可能包含未经验证的数据，然后针对性地设计系统的其他部分。比如，用户只能写入他们自己可读取的数据，这是可行的方式。第二，可以将某些写操作委托给自定义Web服务，比如可以使用Lambda函数来进行验证，并且以一种安全的方式写入数据。我们将会在第6章的“使用Lambda构建微服务”中详细介绍。
不一样的身份模型
外部身份管理是我们这本书构建的应用中的一个独特功能。使用Web服务来管理身份信息有很多好处，但对你来说这种机制可能有点陌生。与将用户信息和其他数据保存在一起的传统方式不同，这些用户资料会保存在一个独立访问的数据存储服务中。如果使用这种方式构建无服应用，一些在数据库中处理用户数据的方法（比如用一个ID关联一张User表）就没办法实现。
失去控制
此外，将所有请求路由到统一的中间层可以实现某种程度的控制，这在某些情况下是非常有用的。比如，拒绝访问攻击和其他一些攻击有时候可以在应用服务器上进行阻截。对你而言，放弃对身份认证的直接控制可能想一想都觉得可怕。我们后面在第7章会用一整章来专门探讨这些安全问题。
规模与成本的关系
最后，你需要了解这些服务的开销。虽然能够自动扩展应用这一点非常厉害，但易于扩展同时也意味着花钱更容易。你需要了解这些服务的定价策略以及当用户增加时这些价格的变化。我们后面会在第8章中深入讨论应用的成本。
既然你已经了解了无服Web应用的代价，我们可以开启这本教程，探索一下无服Web应用是如何实现的。在教程中，你可能会发现这种设计方式为你开发的Web应用带来的其他好处和限制。一旦知晓了无服应用的全貌，就可以判断下一个项目是否适合这种方式了。使用自己的工作空间
为了学习无服Web应用的知识，我们将在本书中搭建一个JavaScript编程解题应用作为示例，名字叫LearnJS。它会向用户展示一些简单的编程题，然后让他们用JavaScript作答，并按下按钮检查答案是否正确。这个应用的样子如下图所示。
我们将会从后往前搭建这个应用。本章我们将会部署它，然后测试，再加入一些应用逻辑。在那之后，我们再来思考架构设计。
如果你对现代开发者们拥护的这种迭代增量式开发风格不熟悉（我本来想把它叫作敏捷开发，但是它和敏捷的涵义还有所不同），这套流程看起来是完全错误的。还没有构建好应用我们怎么部署呢？还不知道要让应用做什么，怎么先写自动化测试呢？还有，我们是不是应该在动手之前先考虑一下架构设计呢？
如果你对此有疑问，没关系，我们将会一步步实现这个流程。一旦完成之后，你将会理解，甚至是赞同这种方式。不仅因为它是学习新技术的绝佳途径，而且也是构建软件的有效方法：前进一小步，评估当前状态，不断重复此过程，直到客户满意。
使用Git进行代码管理
Git是一个代码管理系统。与其他系统一样，Git能帮你跟踪代码的变动，保证代码安全，以及与他人共享。如果你对它不熟悉，可以看看下面的介绍。
Fork一个项目意味着创建一个自有的副本。如果你在Github.com上创建一个账号，再查看你的工作空间项目，应该可以在页面右上角看到一个“Fork”按钮。单击按钮，过几秒后，Github就会为你创建这个项目的副本。现在你需要把它复制到本地电脑上，这个过程称为克隆（clone）。使用一个Git客户端，你能将整个工作空间都克隆到自己电脑的本地目录上。一旦完成，就万事俱备了。
想要了解更多如何使用Git和Github的内容，参见Github Guides。
一开始，你需要fork一个在Github上准备好的工作空间。使用这个工作空间能让你专注于构建应用和学习相关知识，而不是把时间花在搭建必要但不相关的基础设施上。在进行下一步操作之前，使用以下命令克隆被fork的工作空间（填入你的Github用户名）：
要理解接下来会做什么，首先需要理解现有的代码。刚才克隆的工作空间中有一个public文件夹，里面包含了一个空应用。这个应用没有任何功能，它的标记（markup）也很快就会被替换，但它包含了所有我们需要的基本工具。
在构建应用时，我们主要会修改public文件夹下的三个文件：index.html、app.js和app_spec.js。我们会在index.html中添加应用的标记。这就是我们单页Web应用中的“单页”。使用自己顺手的文本编辑器，打开这个文件，查看一下内容。在
元素中，你将会看到这个预备好的工作空间里我们必须使用的一些库。应用里第一个库是标准化CSS基准库，它保证了我们的基本样式在所有浏览器中都是一致的。后面我们会引入Skeleton，一个响应式CSS样板库。Skeleton提供了响应式网格和一些小的CSS组件，可以用于样式和布局。我们还引入了Skeleton的默认字体Raleway，托管在Google字体库 。还有一个引入的库是jQuery 2。我们用jQuery来做许多事情，比如搭建应用视图、视觉动画和监听事件。
第二个文件vendor.js包含的库要么是我们应用自定义的，要么是不够流行而没有放在CDN上的类。迄今为止，这个文件包含的唯一东西是一个AWS（版本号为2.2.4）JavaScript开发库的自定义子集，包含了以下几个服务类库：
·CognitoIdentity
·CognitoSync
·DynamoDB
·Lambda
·STS
元素里的另一个脚本为app.js。到目前为止，这个文件是空的。这里就是我们添加用JavaScript编写的应用逻辑的地方。它不仅会包含应用的领域特定逻辑，而且包含像路由器、模板函数和数据绑定代码这样的基础设施。元素里的最后一项是一个试读结束[说明：试读内容隐藏了图片]