-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose the lambda context in the virtual alexa filter() method #68
Comments
So I understand passing the context. That's easy :-) With regard to sorting out the "context 🔥" - I do understand better the issue based on your description. Thank you for that. What do you think would be the best way to address this? Here is my stab at it:
Am I on the right track? |
Yes exactly. simulateGateway flag is great. BTW in the response there are more attributes you can use in BST proxy: http response code and return headers. Maybe another flag to simulate the lambda event and context when the lambda is hooked directly to an Alexa skill (i.e. the event is a vanilla Alexa event - no API GW). I'm not sure what the format is. Or is it the same as the current BST format (event = payload)? |
I forgot. for the simulateGateway you also need to push the request info (path, queryString) onto event. And the body is the JSON string not the object (like in BST). |
I haven't read all of the documentation yet (forgive me please), but can you share how to pass in the context? Btw, my team and I are loving Bespoken! |
@dgreene1 We meant adding the changes to pass the lambda context. Which we haven't done yet. But do you mean the same, or do you mean the context used when an alexa session have more than one interaction. If it's the second, the instance keeps the context alive by default |
The ability to tweak the lambda context as well in VirtualAlexa (filter function) would be a nice feature. Currently it only offers the request (which is the alexa payload in case of BST tools).
Use case
Our lambda is exposed with the AWS API GW (with Serverless) and it serves multiple skills, both on Alexa and Google Assistant and it relies on the request path to figure out the platform and the skill.
We use the BST proxy for debugging, and the Virtual Alexa for unit testing. The BST proxy puts the request path and the query parameters into the lambda context (request attribute). We need to mock that with VirtualAlexa in the unit tests.
But there is a bigger picture...
It would be really cool if the BST tools would offer an option to simulate the event and context format of the API Gateway Lambda Proxy. This is default with Serverless or ClaudiaJS installations. The important difference is that Amazon uses the event to pass in information about the HTTP request (BST sends the payload in the event). Also Amazon's callback response format is different too: they want you to wrap the response into a simple object.
The bottom line is this: the consolidation of the lambda event and context structures would make the code simpler for lambda projects exposed with Serverless or ClaudiaJS (anything that uses the default API GW Lambda proxy format).
To illustrate the "lambda context hell" we are in, this is what we call first thing in the lambda handler to sniff out the environment:
The text was updated successfully, but these errors were encountered: