聪明的客户端，木讷的服务器？AWS 发布浏览器中使用的 JavaScript SDK

多年以来，虽然依旧依赖于服务器侧代码来做一些繁重的工作，但开发者一直在要求客户侧代码来分担更多的内容。AWS 发布了一套 JavaScript SDK，以期改变这一模式。该 SDK 能够在浏览器中安全地访问 AWS 服务，从而在某些情况下消除了对任何服务器侧代码的需求。

在宣布该 SDK 开发者预览版的博客文章中，AWS 团队概述了这套 SDK 支持的四项 AWS 服务：

使用 SDK 可以直接调用以下 AWS 服务：

• Amazon S3 ：存储和检索任何规模的对象
• Amazon SQS ：对消息队列进行读取和写入
• Amazon SNS ：生成和处理对移动设备或其他分布式服务的通知
• Amazon DynamoDB ：以任何访问速率，存储和检索任何总量的数据

对于上述四项服务，SDK 能够访问其全部功能。我们可以创建和填充 S3 存储桶、管理消息队列、创建、填充和查询 DynamoDB 表，并使用其他更多功能！

对某些应用来说，这一功能能够完全消除对 Web 服务器的需求。亚马逊 S3 支持静态 Web 应用托管，这使得向存储桶上传网站并在其中运行成为可能。静态应用可以通过诸如 S3 、 Dropbox 以及 nginx 这样的高性能 HTTP 服务器，轻松地进行扩展。

软件先驱 Dave Winer看好这项发布，并认为我们正处于一场“真正的技术突破”的风口浪尖。现在，静态应用的开发者们不必构建调用 Web 服务的代理服务器并必须扩展以满足需求，而是能够只依赖 Web 服务提供者来交付必要的扩展。在 2012 年，Dropbox 就认可了这一模式，而且 Winer 预见了未来。

一年以前， Dropbox 做了一些神奇的事情。

基本上，他们在 dropbox.com 中吸收了代理服务器的功能，使人们不必再创建中间服务器。出乎意料的是，人们也无需编写服务器软件来构建链接到 Dropbox。这样就消除了扩展问题；也避免了集资或是把用户卖给广告商的情况。

扩展工作本身依旧需要完成，但现在是由 Dropbox 来进行。他们解决这个问题的方法，并不是向广告商兜售用户，而是向使用服务的人们收费。完美的方案。这种经济模式恰到好处。

Winer 一直鼓励其他公司学习这个模式，他很高兴看到 AWS 发布了这样的 SDK。

我一直尝试尽可能向这些公司里的其他人游说，鼓动他们去做与 Dropbox 同样的事情。如果其中有那么几家听了我的建议，那么我们很快就能看到关键的大规模运用，而后某些真正有趣的东西就会浮现出来。各种类型的应用都有可能。然而没有人去做这样的事情——直到今天，当亚马逊公布其用在浏览器中的 AWS SDK for JavaScript 。理论上说，该 SDK 对亚马逊的 Web 服务的事情，与 Dropbox 所做的相同。从亚马逊的公告来看，人们可以直接访问服务器，来做那些过去需要使用代理服务器才能做的事情。

虽然不是所有的公共 Web 服务都拥有认证层，但显然 AWS 拥有。AWS 是如何解决纯客户侧应用所面对的认证问题的？

如果曾使用过 AWS SDK 和 API，那么你就会知道，每个请求都必须得到你的 AWS 证书的签名。然而几乎毫无疑问，谁都不希望在 HTML 或 JavaScript 应用中包含自己的证书，因为任何人都能够查看并使用它们。相反，你应该使用我们的 Web 身份联盟特性，对你的应用的用户进行认证。通过将 WIF 结合到你的应用里，你可以利用公共身份提供者（ Facebook 、 Google 或登录亚马逊），来创建一系列临时性安全证书。

AWS 的身份和访问管理（IAM）服务，让开发者能够注册某个应用与特定的身份提供者，以便通过该特定提供者认证的用户能够获得预定的角色。他们近期发布的 Web 身份联盟体验网站，简化了模拟这些身份交互并观察输出的工作。对于想要为其 AWS 资源制定身份政策并测试用户访问场景的开发者来说，这将有所帮助。

按典型的 AWS 风格，现在已经有了一个专门用来学习SDK 的网站，提供了基础性的帮助演练和支持论坛。这一新兴的支持服务，只是整个AWS 家族的一个子集，但它面向需要诸如存储和消息等能力的应用构建者。我们有理由期待SDK 在未来会增加额外的服务，例如ElastiCache、Simple Email Service，甚至是EC2.

查看英文原文： Smart Clients, Dumb Servers? AWS Releases SDK for JavaScript in the Browser