聪明的客户端，木讷的服务器？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