I’m not sure if I’m missing something here or not. So if I understand it correctly previously, the legacy mode of Lambda had the feature (LAMBDA_FORWARD_URL) of forwarding requests to an external service. This is probably the best scenario for cases when the application depends on some external LAMBDA.I’m trying to understand:
If such feature exists in the new mode?
If not, what was the reason behind removing it, considering its value? Is there any discussion somewhere I can take a look.
What’s the best way to implement such scenario; the application depends on an external Lambda and I’m happy to mock the response using a mockserver instance. For that I need to be able to forward Lambda requests the mockserver instance.
Currently I’ve written a dumb proxy in Python and deploy it as a Lambda. But that’s overkill for such a simple scenario.
Any help would be appreciated. Thanks.
The feature was initially introduced to mitigate limitations in the old Lambda implementation. Our new Lambda implementation achieves (almost) perfect feature coverage and parity with AWS following meticulous parity testing. Hence, forwarding Lambda requests was not a priority in the re-implementation.
Could you clarify your use case: What is an “external Lambda” (hosted on AWS?) in your context? Why can the Lambda not be emulated in LocalStack?
You’re right. What you mentioned is clear. Let me elaborate, if I may.
Let say we have foo-service (a normal Spring Boot application) maintained by Foo team and bar-lambda (an AWS lambda) maintained by Bar team. Now, foo-service has a dependency on bar-lambda, i.e. it makes a call to the lambda (directly using a Lambda client in AWS Java SDK, not via API Gateway). Now in foo-service integration tests, I need a way to mock bar-lambda. One way is to mock the Java class in the code, but it’s not quite easy in our integration tests (they’re more E2E tests). So what I do is to spin up a localstack instance, create bar-lambda, but deploy a simple python script that forwards incoming request to a mockserver instance that is running in the same docker-compose stack.
In a nutshell:
My service depends on a Lambda maintained by another team.
I don’t care about the internal of the Lambda, just need to mock its API.
I’d like to provide the mocked responses via a mockserver instance.
The way I see it, this is a typical use case for normal microservices that depend on AWS lambda functions. And my hack/solution described above is a bit of an overkill, for two reasons;
the python script that needs to be maintain, deployed, etc
the fact that it spin up another container which needs access to mockserver instance, networking is not straightforward.
I never tried it, but LAMBDA_FORWARD_URL sounded like what I’m talking about.
So I was wondering why the feature is removed and what’s the best way to achieve the objective in the new version.
Thanks.
Rad
LAMBDA_DOCKER_NETWORK=bridge (Docker default) Docker network driver for the Lambda and ECS containers. Needs to be set to the network the LocalStack container is connected to. Limitation: host mode currently not supported.
Thanks for the reply.
Yes I had seen the network documentation and managed to get it working (took me a while, but finally managed to do it )
My question is more specifically:
Unless you disagree with me, I’d argue “run Lambdas via an external service.” (copied from LocalStack documentation) is a pretty common use case, i.e. I’ve got a service that depends on a Lambda, I don’t care about the lambda implementation, I just need to mock its API.
If we agree on the above, assuming I’m not missing anything, the question is why the feature is removed? Is there any discussion going on regarding the feature? Can we ask for it to be added back as a feature request?
I gave some details in my previous reply, not sure if you saw it.
Let me know if you need more details.
Thank you very much for sharing your use case. That is indeed a very interesting scenario.
Makes sense.
The previous implementation of LAMBDA_FORWARD_URL sent a POST request to the given URL with the lambda-function-name in the header and input event as JSON body. I guess that should be sufficient to cover the mockserver scenario or are there any special requirements to consider?
I added the feature to our internal Lambda backlog. We continuously monitor popular GitHub feature requests and Discuss posts when prioritizing our efforts to improve LocalStack.
Can you please confirm I still can use the legacy mode with LAMBDA_FORWARD_URL in V2 to achieve what we’re discussing. Asking because last time I tried and failed to get it working. I thought the feature is removed from V2 completely. I can give another try if you confirm the feature is not removed.
As for the feature request, that’s right. In essence the question is, how to mock Lambda functions in LocalStack. On that note, to backup it with another reason, the Lambda image seems to be AMD64 architecture and after I switch to Apple Silicon M2, I feel the speed of tests degraded. That could be because of running the Lambda AMD64 container in simulation mode. I haven’t measured it, but I suspect that’s the root cause. Does that make sense to you?
Cheers,
Rad
PS: is there any GH issue or something I can upvote? Or should I create one? Thanks.
The feature is not removed LocalStack v2 but the old Lambda provider implementation (PROVIDER_OVERRIDE_LAMBDA=legacy) is deprecated and not actively supported anymore.
Feel free to report and upvote an enhancement request on GitHub.
Since LocalStack 2.0, Lambda functions execute in Docker containers with the target platform linux/amd64 or linux/arm64 depending on the instruction set architecture configured for the function (x86_64 by default or arm64). This behavior can lead to errors if the host system, the Docker image, or the code/layer of the function do not support the target architecture. If you prefer to execute Lambda functions natively, you can set the configuration variable LAMBDA_IGNORE_ARCHITECTURE=1.
If your Lambda functions are cross-architecture compatible, you could try out LAMBDA_IGNORE_ARCHITECTURE=1. Lambda performance should be much faster than in LocalStack v1. Let us know if anything performs slower than expected (c.f., measurements on M1 MacBook).
)
GitHub feature requests and Discuss posts when prioritizing our efforts to improve LocalStack.
) It works like a charm. Thanks.