nodezoo / monorepo

Nodezoo system monorepo.
MIT License
2 stars 2 forks source link

AWS Lambda env #16

Open rjrodger opened 2 years ago

rjrodger commented 2 years ago

Deployment to AWS Lambda needs to work with the constraints of the Lambda architecture - in particular, a lambda should not call another lambda. This is possible, but a bad idea, as you pay double - lambdas are charged against wall clock time.

Lambdas that serve synchronous request/response events need to be fully self contained (apart from calling DynamoDB, Search, Cognito, etc). Lambdas that are asynchronous can send and receive message using SNS.

Thus we can use the following:

The existing code in deploy/aws will help - the lambda can be copied for the async case. It can also be used as the basis for the sync case, expect that it will use seneca-gateway, not sns-transport.

The public and account monoliths can work using express also - there is an express adapter for lambda:

const awsServerlessExpress = require('aws-serverless-express');
const app = require('./app');

const server = awsServerlessExpress.createServer(app);

exports.handler = (event, context) => {
  return awsServerlessExpress.proxy(server, event, context, 'PROMISE').promise;
};

NOTE: we still need to use seneca-gateway for inbound messages.

By using express in the lambda we should be able to minimize the mismatch between lambda and normal web server architectures.

There is one aspect we may need to refactor - where a sync service waits for async replies (e.g info) - in this case we may need to change the logic to perform a retry in, say 500ms, rather than waiting for the async messages.

The deploy/aws code also shows how to set up the SNS queues

The html and static content will need to be uploaded to S3.

rjrodger commented 2 years ago

User login: if we use express as above, we can get the cookie based login working first. That leaves supported a Cognito setup as a nice to have rather than a hard dependency