QnABot Lambda Extension Hooks about qnabot-on-aws HOT 6 CLOSED

If we think of the Lambda hooks as middleware then there are three possible places to register the lambdas

1. to individual questions
2. to topics
3. globaly (great for analytics)

from qnabot-on-aws.

User will need to supply two things

• lambda Arn to be called
• IAM role that can be assumed so the fulfillment lambda can invoke the custom lambda

from qnabot-on-aws.

I think there are four lambda hooks

1. preproccess-lambd(sync call)
   called before ES query, called for all requests. this would allow designers to make changes to the ES request and possibly redirect behavior.

2. postprocess-lambda(sync call)
   called after ES query. lambda name comes from lambda field in response. this would allow dynamic responses

3. response-lambda(sync call)
   called with response object for all requests

4. finish lambda (async call)
   called before sending response. this is where you could put analytics

from qnabot-on-aws.

problem)
if a lex request has to call 4 lambdas (pre/post-process, response, and itself) and all have to cold start then a lex request could take a longtime to finish.

from qnabot-on-aws.

Yeah, I think 4 lambdas is overkill, and I share your latency concern. For now, I believe most/all known extension use cases can be met with support for a single optional Lambda registered at the item level.

from qnabot-on-aws.

fixed in v2

from qnabot-on-aws.