@PerfectedTech thanks for the update!

Breaking the application definitely makes sense to me. The one word of advise is to make sure you are using a cost effective way to do that, so your Lambda/API Gateway/etc. costs do not end up being higher than running a loopback server straight out of EC2 (or the like).

Here are some thoughts that come to mind related to loopback, Lambda, and serverless in the context of solving this issue:

Break down large logical chunks that can be run as different groups of API invocations and share the same dependencies (staying under the stated 250MB limit) as different Lambda functions. This means having multiple serverless functions and should be pretty straightforward to implement. The challenge here will be to manage the shared dependencies so serverless will avoid packaging unnecessary ones. I used serverless package and artifact to accomplish this along with gulp to control the dependencies I wanted packaged for each function. I tried using exclude/include but it did not work very well for me.
For specific workflows, I used SNS, DynamoDB, etc. so one Lambda function triggers another. Let us say I have a table update and something else that needs to happen after that. You can then break down the code so the before and after pieces of the workflow happen in different Lambda functions. This might get very weird when using loopback as a loopback app may be bundling the code for before/after in the same files (and the dependencies might be the same, so no space saved there).
Another way to tackle this is to invoke a Lambda function using the AWS-SDK from your Lambda function (note that aws-sdk does not need to be added to your uploaded dependencies as Amazon makes it available inside Lambda). I have not used this approach as the synchronous alternative means double Lambda charges and the asynchronous one comes across as increasing the troubleshooting complexity, so I would use this as a last resort.
While researching on Lambda functions triggering other Lambda functions I came across this article. While I do not believe this makes much sense in a loopback app, as I do not know your specific use cases/architecture, I figured it was worth sharing it ;-)

I will close the issue and pin it so others with a similar issue can easily benefit as you post updates ;-)

Loopback Server and AWS Lambda hard limit #2

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions