-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Remove direct imports of lambda provider #6737
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
Conversation
fced3a8
to
365692b
Compare
dc8e437
to
961fe21
Compare
961fe21
to
485cb60
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked too much over the apigateway,dynamodb parts but the rest seems fine to me 🚀
Hope we can merge this soon, so we have some proper boundaries between Lambda and the other services again 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had only a quick glance over the things not SNS related, but LGTM, thanks for moving it, it makes more sense for it to be in the SNS provider! I'm glad to see us use the external client between services and API! 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this @dfangl, I can speak for API GW, is not always easy to understand the code. I only have one comment regarding the response coming from the lambda that used to be dependent on the lambda runtime, otherwise LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great, thanks for churning through the changes 💯
6cc113c
to
08aed23
Compare
Goal
When moving to the new lambda provider, we want to avoid all imports which rely on the logic of the old provider, to make seamless switching possible
Main changes
MAIN_DOCKER_NETWORK
in order to replace the usage ofLAMBDA_DOCKER_NETWORK
for other services as well (as it is a misnomer, and to avoid tight coupling of lambda with other services). For now, until a major/minor version release, this variable falls back toLAMBDA_DOCKER_NETWORK
to simulate current behavior. /cc @thrauSplitting other services from lambda modules
process_sns_notification_to_lambda
to sns module (it belongs there thematically, since SNS is responsible for the payload) and invoke using boto client /cc @bentskujson.dumps
will not work), and removal of processing of everything not a boto response (flaskresponses, lambda invocation results etc). Also moved a test (for the apigw event payload) from lambda unit tests to apigatway unit tests (also belongs there thematically) /cc @calvernaz