Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS Lambda env #16

Open
rjrodger opened this issue Sep 14, 2021 · 1 comment
Open

AWS Lambda env #16

rjrodger opened this issue Sep 14, 2021 · 1 comment
Assignees

Comments

@rjrodger
Copy link
Contributor

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:

  • a public monolith - same idea as env/local, but only include services that are used for the public api - eg. search, login
  • an account monolith - same idea as env/local, but only include services that are needed for account actions - e.g bookmarking
  • individual lambdas for services that support async messages - e.g npm, github

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants