-
Notifications
You must be signed in to change notification settings - Fork 41
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
Lambda modules organization? #57
Comments
@bpholt and I chatted on Discord. Here's what we've decided for now:
|
IMO: natchez in core is fine, events in core is fine as long as there are no extra dependencies. |
Yep, I'll make sure to drop circe-generic. |
covered in #77 |
I think the current organization is good. |
This keeps coming up, e.g. #2, #6 (comment), #48, #50 (comment). So at some point we should decide what we want to do :)
Just some assorted thoughts, all IMHO:
lambda-events
separate fromlambda
is b/c a shapeless dependency (historically) was a big deal. Not sure if that's true anymore, and irrelevant to Scala 3 or if we hand-write our encoders/decoders.lambda-events
and others are with specialized lambdas. But also, these models aren't really shared interfaces, just kind of helpers ... if e.g. the CloudFormation lambda wants to define its own version of its events and eschew this dependency, I think that could be fine.Lambda
that pair events with results. This idea makes me consider if we should just mergelambda-events
withlambda
.lambda-natchez
intolambda
so we can offer tracing middleware out-of-the-box.natchez-core
is lightweight.The text was updated successfully, but these errors were encountered: