Hacker News Reader

Comment by DocSavage | Hacker News Reader

Thanks for sharing. I've just started work on a server-free AWS architecture, but instead of using the AWS API Gateway feeding into Lambda, I'm working on static pages with AWS SDK for Javascript (served from S3) talking directly to Cognito, RDS and S3 with lambda for async processing:

https://aws.amazon.com/sdk-for-browser/

I'm surprised I haven't seen more discussion of SDK for Javascript since it removes a lot of the server requirements. Have you considered using AWS SDK for Javascript, or do you explicitly want a REST API as an abstraction layer? The API certainly provides some advantages if you ever want to migrate off AWS. In my case, the lambda functions get invoked by particular events on RDS, S3, or manual/browser triggers instead of AWS API Gateway invocation.

View on HN

How to protect access keys to S3 and RDS in this approach. Everyone can extract them from your HTML/JS code and use for their own purpose.

You can use Amazon's IAM Web Identity Federation and grant access to resources only for users that have signed in with Google, Facebook etc. with approved user identifiers.

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/browser-co...

So basically, instead of embedding the AWS access keys in HTML, you use AWS.config.credentials = new AWS.WebIdentityCredentials(...) with the OAuth access tokens you get from Google or Facebook.

For S3, which permits IAM authorisation, there's AWS Cognito as a role-based token vending machine.

For RDS, I suspect DocSavage is likely to soon learn that browsers don't speak RDBMS wire protocols; they'll need a CRUD wrapper at least. The canonical AWS "serverless" solution would be API Gateway + Lambda.

It just happened :/ I actually was planning on DynamoDB until an architect at AWS Loft convinced me last Friday that RDS was easier for my modeling. Won't work, though, if only RDS management is exposed through the Javascript and not the actual RDBMS wire protocols. Back to DynamoDB.

I'd like to see this when you get finished. I'm looking for a new way to do static webpages that's fast and hassle free.

Unfortunately my client is closely coupled to a venture I'm doing on the side. I won't be open sourcing it. If it's just static web pages you need without mutable data, you can do that directly off Amazon S3. There are lots of blogs and open source projects for that:

http://stout.is/

https://sysadmincasts.com/episodes/48-static-sites-using-aws...

If you sprinkle in AWS SDK for Javascript in the browser, you can handle mutations directly into various persistence services without needing EC2. I'm still very early in my exploration of this approach so I was hoping to see some case study myself. If there's no direct way to invoke lambda from a service event (e.g., an RDS mutation), you could invoke it from the client after returning from the RDS request.

Checkout Jekyll, I’m having a great time building https://github.com/anishavasandani/suchbrooklyn.com

I wrote parched and parched-tasks-web app specifically for this.

I’m almost at a point where I think static websites are a solved problem. Compile your website with whatever (Jekyll, Octopress, etc), save it to GitHub for good measure, and push it to an S3 bucket with CloudFront og CloudFlare in front of it.

You can always find somewhere else to host your stuff, but I’d say I’m pretty happy with a deployment workflow that’s basically

    bundle exec jekyll build
    s3_website push

Aaand you’re done. And you can even roll those two into a pre- or post-commit hook.

I like this approach. I'm all about removing server requirements!

For now, I favor the traditional REST API layer because REST APIs are well understood. They also may require less effort to access via IOT devices and expose publicly for other developers to hack with.

Overall, I'm interested in the best. If you have thoughts on how to incorporate this approach into JAWS for optimal effect, I'm definitely paying attention.

As far as JAWS goes, the next step is to be able to define your API in JSON via Swagger, and then import it into AWS API Gateway to instantly create/update your API. This should dramatically reduce development time and make it much easier for everyone building their JAWS REST API :)

I would view your approach as a complimentary architecture. At some point, I'll want to provide developer APIs that can be throttled, measured, etc, and the API Gateway is a perfect interface for that. But sometimes you'd want client code that directly uses AWS services without the intermediary, particularly since the surface area of all AWS services is massive and generated JAWS REST APIs would likely be smaller, domain-specific interfaces.

I am also experimenting a serverless architecture on top of AWS. Just like you, I tried to directly use S3 + cognito, which is great. The only problem I see is that it is not possible to limit the space used by a bucket and, therefore, it could be used as infinite storage by malicious clients.

I've checked out with AWS people [1] and asked on stackoverflow [2], but it seems not possible yet. They suggested me to use lambda to delete unwanted content after it was uploaded, which surely works, but is a waste of bandwidth and of lambda time. Did you find the same problems? Any other solution?

Beside, it looks like a great approach, but it surely ties you to AWS way more than other approaches.

[1] https://twitter.com/davide_vernizzi/status/62099420049093017...

[2] http://stackoverflow.com/questions/31412335/can-i-limit-the-...

I've been working on something like this as well and the biggest problem that I have found is that there is a hard limit of 100 S3 buckets per aws account. Which, unfortunately makes it impossible to use S3 in the manner I had intended.

AWS has hard limits, but usually can be easily overcome just by asking to their support. We increased many times the hard limits on EC2 instances and EIP.

That's true, but the S3 bucket limit, just like the VPC security group limit, is fixed at 100, even if you are Netflix. --- Edit: Wow, what a difference a day makes.

They actually just changed this yesterday: http://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-...

> Bucket Limit Increase: You can now increase your Amazon S3 bucket limit per AWS account. All AWS accounts have a default bucket limit of 100 buckets, and starting today you can now request additional buckets by visiting AWS Service Limits.

look into namespacing your buckets. a bucket is not the same as a table. aws works in massive scale production and can suit all kinds of needs. the good folks at the aws popup loft in SF set me straight on this one

Unfortunately namespacing won't work for us. We need the ability to point a domain name at a bucket. Can't do that with a folder inside a bucket. If I am incorrect on this, it would be great if you could set me straight too.

Reply on news.ycombinator.com