For years now, developers have been asking their client-side code to do more work while still relying on server-side code to do some heavy lifting. AWS is shaking up that model by releasing a JavaScript SDK that securely accesses AWS services from the browser, thus eliminating in some cases the need for any server-side code.
In a blog post announcing this developer preview, the AWS team outlined the four AWS services supported by the SDK.
You can make direct calls to the following AWS services:
- Amazon S3 to store and retrieve objects at any scale.
- Amazon SQS to read from and write to message queues.
- Amazon SNS to generate and process notifications to mobile devices and other distributed services.
- Amazon DynamoDB to store and retrieve any amount of data, at any access rate.
The SDK supports access to all of the functionality provided by each of the services listed above. You can create and populate S3 buckets, manage message queues, create, populate, and query DynamoDB tables, and much more!
For some applications, this functionality could remove the need for a web server entirely. Amazon S3 supports static web application hosting, thus making it possible to upload a website to a bucket and run it from there. Static applications scale easily through containers like S3 and Dropbox, or high performing HTTP servers like nginx.
Software pioneer Dave Winer is bullish on this release and thinks we’re on the cusp of a “true tech breakthrough.” Instead of building proxy servers that call web services and must scale to meet demand, developers of static applications can instead rely just on web service providers to deliver the necessary scale. Dropbox embraced this model in 2012, and Winer saw the future.
Then a little over a year ago, Dropbox did something amazing.
They basically sucked the functionality of the proxy server into dropbox.com, making it unnecessary to create an in-between server. All of a sudden you don't need to write server software to build an app that connects with Dropbox. Poof! There goes the scaling problem. And also the need to raise money or sell the users to advertisers.
The scaling still has to be done, but it's done by Dropbox. They make it work not by selling users to advertisers, rather by charging people to use their service. Perfect. These economics feel just right.
Winer has been urging other companies to get on board with this model and was pleased to see AWS introduce this SDK.
I've been trying to talk with whoever I can at these companies to urge them to do the same as Dropbox did. If a few of them do, I reasoned, we'd get to critical mass sooner, and then some really interesting stuff would happen. All kinds of apps would be possible. Alas, none had done it -- until yesterday, when Amazon announced their AWS SDK for JavaScript in the Browser. Theoretically, it does for their web services, what Dropbox did for theirs. The claim is that you can call directly to their servers to do the kinds of things you used to need a proxy for.
While not every public web service has an authentication layer, AWS certainly does. How does AWS tackle the authentication challenge of purely client-side applications?
If you have used the AWS SDKs and APIs in the past, you know that each request must be signed with your AWS credentials. You almost certainly don't want to include your credentials in your HTML or your JavaScript where anyone could find and use them. Instead, you should use our web identity federation feature to authenticate the users of your application. By incorporating WIF into your application, you can use a public identity provider (Facebook, Google, or Login with Amazon) to initiate the creation of a set of temporary security credentials.
The Identity and Access Management (IAM) service from AWS lets developers register an application with a particular identity provider so that users who authenticate with that particular provider can assume a pre-defined role. Their recently released Web Identity Federation Playground makes it easy to simulate these identity interactions and observe the output. This should help developers who want to craft identity policies for their AWS resources and test user access scenarios.
In typical AWS fashion, there is already a dedicated website for learning about the SDK, basic how-to walkthroughs, and support forums. This initial crop of supported services is only a subset of the entire AWS family, but are geared towards application builders who need capabilities like storage and messaging. It’s not unreasonable to expect the SDK to support additional services – like ElastiCache, Simple Email Service, or even EC2 – in the future.
