https://serverless-stack.com/ logo
Join Slack
Powered by
So what are you guys doing to keep your lambda cod...
# help
a
So what are you guys doing to keep your lambda code organized? Any specific frameworks or patterns? So far I'm going freestyle, and it works quite well, but I'm not sure if I'll be able to still handle the project when it gets much larger.
t
We use a framework called https://laconiajs.io to help us consistently implement the ports and adaptors pattern. Its helped quite a bit and cutting out the amount of AWS specific boilerplate code we have in our lambda handlers and made our codebase a lot more testable
t
^ I do something like this but without the framework
strongly believe in not having business logic in functions and developing a core library instead
but I don't follow the hexagonal pattern exactly, I tend to do a light DDD approach where domains are coupled with the data stores they use
b
if there's a single thing to not do is to have boilerplate code (database, queues, external apis, etc... operations) directly in the handlers.
a
laconia looks very interesting, thanks for linking it
@Thomas Ankcorn Seems there hasn't been much activity lately on their github, though
I found middy as well, seems to be a bit more active, but laconia's approach is a bit more elegant in my opinion. Although middy might be easier to use for people who already know express, for example.
t
We use Laconia at work and have made a few contributions for bug fixes that were accepted in good time.
a
yeah, I think I'll try laconia first. The way you simply wrap your business logic in additional functions speaks to me on some subconcious level 🙂
r
Came across Laconia in this thread and looks interesting. Just reading their docs and on the Core Concepts page and it shows this:
Surely that’s wrong - two different assignments to the 
const handler
?
Just wanted to get my head around the flow but this apparent typo makes it unclear which is their definition of a handler vs the normal, lambda definition
t
I think that is supposed to be 
exports.handler = handler(adapter(app))
a
yep
It is probably not supposed to be real working code, just a showcase of how the responsibility of creating the dependencies is extracted from the adapter
t
a
@Ross Coundon here is a real example of basically the same thing:
Copy code
const laconia = require("@laconia/core");
const { s3 } = require("@laconia/event");

const app = objectFromS3 => console.log(objectFromS3);

const adapter = app => async event => app(await s3(event).getObject());

exports.handler = laconia(adapter(app));
it shows the separation of your business code (app), custom adapter and finally how everything is wrapped together and exported
r
Thanks guys, I’ll have a play a bit later
a
actually, my example doesn't show the dependency injection
@Thomas Ankcorn I added a comment to your PR, I think instead of introducing exports, the example could be improved by renaming the first handler definition to 
laconia
, because this is actually more or less what laconia does
then the last line would look like
Copy code
const handler = laconia(adapter(app));
hmmm, although, it might be more confusing even, because the adapter shown is actually also part of the laconia function itself
yeah, it's probably better to just use exports on the last line
t
Doc fix looks like it's gone live, thanks @Ross Coundon
r
That was fast, thanks!
a
nice
Open in Slack
PreviousNext
Powered by