You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
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:
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.
The text was updated successfully, but these errors were encountered: