> to be run in multiple processes I don't know how it could be achieved. You never know which lambda will run the command even if you set a high concurrency level which is overkill for this task IMO.
Could you please provide an explanation on how would you imagine it to work? 😄
heh, I have to imagine a while to explain :D
Could it be possible to send code as normal payload to a “special dev-lambda” that just evals the code it receives and returns the eval results back? 🤔 Am I thinking naively…? Could something as simple as this work as a “dev some code and test it immediately in a real lambda env” kind of thing.. Or do we have something like this already in holy-lambda?
(I’ve been 👀 the project for a while but not tried it in practice just yet.. Nice project btw @karol.wojcik!)
@valtteri if by real lambda env you mean lambda which is deployed then no. You would need something like this https://docs.serverless-stack.com/live-lambda-development (which I am planning to develop soon).
For simple cases in which you develop a simple API you can use bb stack:api to spin a local server. There is also bb stack:invoke which may invoke lambda locally with specified event. If you don’t know how such event should look like you can generate it via sam local generate-event. https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-generate-event.html
Of course bb stack:invoke and bb stack:api rely on official AWS sam local environment, so it’s very close to real runtime. Actually I had no much issues with it maybe except running java11 compiled Clojure :/
There is localstack https://github.com/localstack/localstack which can help you spin kinda „real” lambda dependencies like SQS etc. You can pass urls via envs.json then: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-invoke.html#serverless-sam-cli-using-invoke-environment-file
Yeah, it would be cool to achieve following goals enumerated in live-lambda-development link
• interacting with your entire deployed AWS infrastructure
• It supports all Lambda triggers, so there’s no need to mock API Gateway, SQS, SNS, etc.
• It supports real Lambda environment variables
• And Lambda IAM permissions, so if a Lambda fails on AWS due to the lack of IAM permissions, it would fail locally as well.
However the approach in that solution looks a bit convoluted to me. 🤔 Maybe there’s a more “clojurey” way to just modify the running lambdas on the fly instead of proxying requests to a local machine..?
@valtteri 1. Actually Lambda IAM permissions is a edge case for AWS SAM, because you reference resources via ARN, and AWS SAM makes sure that all necessary permissions are given. 2. Regarding triggers I do agree that local development lacks this feature and it should be emulated via sam local generate-event 3. Regarding real Lambda environment variables I cannot agree. AWS SAM env variables passing strictly emulates how AWS Lambda would pass it. 4. > Maybe there’s a more “clojurey” way to just modify the running lambdas on the fly instead of proxying requests to a local machine..? On babashka runtime you can interactively change sources of lambda via AWS Dashboard. In other runtimes you cannot modify running lambdas on the fly since Lambda environment lives up to 15 minutes and each deployment needs corresponding change in Cloudformation. Even if you would span nrepl server and modify the function you can never know when nrepl will disconnect you. In emacs it always ends up in error which makes the whole development joy vanish in second. Secondly it would not work if someone sets parallel execution > 1. I have few ideas how live-lambda-development, so that it's more clojurey, though. I will create an issue, so that we can discuss it further, ok? If you would like to help I'm of course open for it 🙂 Still though we need to advertise the project more, polish documentation etc.., so that such great features like live-lambda-development env would not be used only by us 😄
However, the biggest selling point to me would be a tight feedback loop iterating lambda development in a real environment. Localstack is OK but on AWS there’s the whole IAM setup, VPC’s and such that are not so nice to mock.
Also connecting to AWS resources directly from local is a bit too tricky if there are private VPC’s involved
That’s why I’m very curious to find a solution for a nice dev-experience with lambda live-development. 🙂 I’m also interested to help if we can come up with a war-plan. (I have plenty of open-source time in the summer)