How to pass parameters to serverless invoke local
Aws LambdaServerless FrameworkAws ServerlessAws Lambda Problem Overview
I'm working on a aws serverless project and need to test the lambda functions locally.
I am using serverless invoke local -f {function_name}
command to test the API calls that does not request any path or query parameters.
My question is how can I use this command to pass any path or query parameter to the function?
Example serverless description
getFoodDetails:
handler: handler.getFoodDetails
events:
- http:
method: get
path: /foods/{food_id}
cors: true
request:
parameters:
paths:
food_id: true
Aws Lambda Solutions
Solution 1 - Aws Lambda
Data string
As being said you can use the --data
option to pass a string data as an event to your function.
serverless invoke local -f {function_name} --data '{ "queryStringParameters": {"id":"P50WXIl6PUlonrSH"}}'
Data file
What you can also do is to pass a --path
to a json file with data as the event
, and within the "event file" define the data you want.
serverless invoke --function {function_name} --path event_mock.json
> You could somehow return the event from a call and save it in a JSON file or grab one from Amazon. They provide some examples: > https://docs.aws.amazon.com/lambda/latest/dg/eventsources.html
Keep in mind that if you pass both --path
and --data
, the data included in the --path
file will overwrite the data you passed with the --data
flag.
Documentation: https://serverless.com/framework/docs/providers/aws/cli-reference/invoke#invoke-local
Solution 2 - Aws Lambda
Use --data
and pass is any format of data you want to send it to the local lambda.
String Data Example:
> serverless invoke --function functionName --stage dev --region > us-east-1 --data "hello world"
JSON Data Example:
> serverless invoke --function functionName --stage dev --region > us-east-1 --data '{ "property1": "value"}'
JSON Data from file:
> serverless invoke --function functionName --stage dev --region > us-east-1 --path lib/data.json
Complete documentation can be accessed from [here][1]
Hope it helps.
[1]: https://serverless.com/framework/docs/providers/aws/cli-reference/invoke/ "Here"
Solution 3 - Aws Lambda
I've tried the answers with the attribute --data
but neither works.
In fact the problem is that the --data
will pass a string value to the framework. So if you write in your javascript file:console.log(typeof(event));
, you will get String
instead of Object
. Which means serverless framework doesn't transform the input to a JSON object correctly. That's why you got xx of undefined error.
My solution is to use the -p
(or --path
) attribute. In your example, follow these steps:
- create a .json file at the current location of your console. eg: test.json
- in the json file write:
{"pathParameters":{"food_id":"100"}}
- in the js file, to get the
food_id
, useevent.pathParameters.food_id
- run command:
sls invoke local -f yourFunction -p test.json
Solution 4 - Aws Lambda
For future reference. Your case would have been solved like this. Just figured it out thanks to Kannaiyans JSON Example.
sls invoke local -f getFoodDetails --data '{ "queryStringParameters": {"food_id":"123"}}'
Solution 5 - Aws Lambda
QueryStringParameters and pathParameters are two different input types.
For the former the accepted response works to me.
For the later is pretty much the same, just replace queryStringParameters by pathParameters
sls invoke local -f {function_name} --data '{ "pathParameters": {"id":"1"}}'
Solution 6 - Aws Lambda
There is also an alternative to all the other options here. I wrote a blog article about this and will link it after going through some of the detail.
There are two basic aspects you need to handle:
- Execute the code in your handler and business logic by passing event objects to your handler
- Handling requests to AWS services in a way that makes it easy to test
For the first one, I just added Mocha to the project and used the unit testing framework as a way to be able to click a button in my IDE and have my code be executed with test data. I can also do local debugging, step through code etc without issue. The added advantage is, if you just set this up, like I have, purely to execute your code, you still have the beginnings of a unit test suite you can flesh out later if you wish
For the second one, its even easier. There is an npm module called aws-sdk-mock and it allows you to register a listener for a specific AWS service and method (such as DynamoDB.query or S3.putItem) and respond to that request with whatever you wish, even errors if you wish to test how your code handles the unthinkable; an AWS service going down.
With the setup of these two elements, I can locally test any handler I develop. Ultimately you will always need to do some integration testing in the cloud as there is just no local substitute, no matter how elaborate or awesome it seems, for the actual cloud services you will be using, but this can get you quite far.
Solution 7 - Aws Lambda
One challenge with local invoke that you seem to have run into is debugging the lambda runtime vs the dynamodb resource. Ideally, you want to invoke both the lambda runtime and the live dynamodb table. Today, serverless local invoke and the AWS SAM CLI both invoke the lambda runtime, but not the live cloudstack.
As long as you have your Lambda's ARN, you can invoke both the lambda runtime as well as the cloudstack with the Stackery CLI. (it's free) Here is an example debugging a serverless framework lambda.
Solution 8 - Aws Lambda
By the way, you can create another function and put into it all test cases for the one you wanted to invoke.
module.exports.testerFunction = () => {
functionIWatnedToInvoke(para1, para2, para3);
functionIWatnedToInvoke(para4, para5, para6);
functionIWatnedToInvoke(para7, para8, para9);
}
then
sls invoke local --function testerFunction