Hacker News Reader

Comment by ac360 | Hacker News Reader

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 :)

View on HN

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.

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.

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.

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