5 ms·

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 stat

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/ 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.

at-fates-hands 11y ago
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.
- DocSavage 11y ago
  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/ http://stout.is/ https://sysadmincasts.com/episodes/48-static-sites-using-aws-s3-cloudfront-and-route-53-1-5 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.
- metabeard 11y ago
  Checkout Jekyll, I’m having a great time building https://github.com/anishavasandani/suchbrooklyn.com https://github.com/anishavasandani/suchbrooklyn.com
- mikewhy 11y ago
  I wrote parched and parched-tasks-web app specifically for this.
- kmfrk 11y ago
  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.
deleted 11y ago
[deleted]
ac360 11y ago
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 :)
- DocSavage 11y ago
  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.
  - tigroferoce 11y ago
    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/620994200490930176 https://twitter.com/davide_vernizzi/status/62099420049093017... [2] http://stackoverflow.com/questions/31412335/can-i-limit-the-size-of-an-object-put-into-s3-via-the-javascript-api http://stackoverflow.com/questions/31412335/can-i-limit-the-...
chebum 11y ago
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.
- kennu 11y ago
  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-configuring-wif.html 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.
- inopinatus 11y ago
  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.
  - DocSavage 11y ago
    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.

at-fates-hands 11y ago

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.

DocSavage 11y ago
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/ http://stout.is/ https://sysadmincasts.com/episodes/48-static-sites-using-aws-s3-cloudfront-and-route-53-1-5 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.
metabeard 11y ago
Checkout Jekyll, I’m having a great time building https://github.com/anishavasandani/suchbrooklyn.com https://github.com/anishavasandani/suchbrooklyn.com
mikewhy 11y ago
I wrote parched and parched-tasks-web app specifically for this.
kmfrk 11y ago
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.

deleted 11y ago

[deleted]

ac360 11y ago

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

DocSavage 11y ago
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.
- tigroferoce 11y ago
  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/620994200490930176 https://twitter.com/davide_vernizzi/status/62099420049093017... [2] http://stackoverflow.com/questions/31412335/can-i-limit-the-size-of-an-object-put-into-s3-via-the-javascript-api http://stackoverflow.com/questions/31412335/can-i-limit-the-...

chebum 11y ago

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.

kennu 11y ago
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-configuring-wif.html 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.
inopinatus 11y ago
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.
- DocSavage 11y ago
  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.