Static website with microservices?

Question

Being the cheap-o that I am, I had an idea the other day of running a web app for less than a nickel per month with AWS:

• Serve a static site (html/css/javascript) via S3
• Client-side code and forms post to Lambda golang microservices via API Gateway
• Use DynamoDB (25 read/s, 25 write/s, 25GB, 1GB/mo in, 1GB/mo out) as database

Would this scheme work with say, cookie and sesssion-based authentication, as the page is being served by one domain name (S3), but the javascript is talking to another domain name (API Gateway)?

What other issues am I likely to run into?

Answer 1

Mike Roberts wrote a very thorough article on serverless architecture and its trade-offs: http://martinfowler.com/articles/serverless.html

Also discovered a framework designed for precisely this which runs on AWS: https://serverless.com/

However, it appears at this time, persistent connections (e.g. websockets) are not supported, which is a deal-breaker for me. I suspect AWS will eventually let API Gateway service the websocket and send its messages to Lambda, but as of today this does not appear to be possible.

Answer 2

One of the things to keep in mind with 'serverless' architectures is:

"What happens if 'this thing' really takes off?"

Most people don't consider how high requests rates for Lambda or DynamoDB can get when your site becomes super popular, or is under a DDOS attack.

Like your request rates, your total charges will also see a significant spike during these events. So for "small projects" where low cost really is important I usually advise sticking some some small VMs to handle processing. While high request rates or a DDOS may overwhelm and take down your service, you likely won't be hit with an outrageous bill.

While serverless is very convenient for getting setup, it can very easily bite back much harder than expected.

Note: If you do find yourself in a situation where your bill is higher than expected, reach out to your cloud provider. Some of them maybe willing to help you with a one time credit for some portion of the charges depending on the circumstances.

But be prepared to explain what happened in detail. I also advise having service logs (not just for your applications), but also for any cloud services which you are using.

Answer 3

I run multiple web apps exactly with your proposed design, and I extracted gofaas, an educational Go and Lambda app, to share the techniques.

Setting a cookie for the static site client is possible with CloudFront and a Lambda@Edge auth function.

Allowing the static site to talk to the API is possible with an API Gateway CORS configuration.

Finally this relies on JSON Web Tokens (JWT) to securely represent an authorization claim between your user, your static site and your API.

Here are some guides for setting all this up:

Static Website Security with Lambda@Edge and Google OAuth 2

API Security with Lambda, API Gateway, CORS and JWT