General question regarding your lambda file struct...
# help
l
General question regarding your lambda file structures. I come from Java monolith background (still struggling to forget the experience 😅), with clear separation of Controllers, Services and DAOs that I tried to kinda adopt as preparation to add some extra TSOA OpenAPI generators post-deployment. Thing is, resulting functions tend to bloat to weird sizes, including more supporting functions and libs than necessary... Simply moving my TS code for handler and companion service functions to a separate file results in roughly x50 smaller bundles post minification. Do I really need to keep each function as a separate file or may I have misconfigured something? 🤕
t
Yeah each function needs to be a seperate file because otherwise esbuild cannot tell what to treeshake out
it's just building a file so will start with everything there
I'm working on this template right now which is what I suggest: https://github.com/serverless-stack/graphql-stack/tree/main/backend
I create a file per function: https://github.com/serverless-stack/graphql-stack/blob/main/backend/services/migrator/migrator.ts and it pulls stuff out of the
@acme/core
library which will house all my business logic
a
Don't forgot developer experience and code maintainability when chasing small bundles though. There's a balance between the smallest bundles by putting every function, down though every dependency, in their own files, and larger bundles but grouping code together for us humans. I take a more hexagonal architecture approach of building my business logic in services agnostic of runtime details, even if that makes the runtime take a few extra milliseconds. Lambda handlers are "adapters" in the hexagonal approach though, with a separate file each and generally do little more than call the proper service. I find the balance works. If you really care about performance over developer experience, write your Lambdas in Rust or Go.
d
are you telling me sst supports rust lambdas already? 😎 joke aside, i do practice adam's advice too.
t
I do the same as what Adam mentions
I do put related functions in the same file because it's unlikely they're really referencing a ton of different domain functions
l
Looks like I do it in a pretty similar fashion (having a healthy balance I mean). Just need to extract the particular lambdas to separate files, again.. Was looking forward towards easy openApi documentation per this implementation: https://serverless-stack.slack.com/archives/C01HQQVC8TH/p1631743686473100?thread_ts=1631726443.470000&cid=C01HQQVC8TH It still requires quite a bit of boilerplate but seemed like a nice combination
Thanks for your insights guys!
Your template looks well thought @thdxr, I'll have to browse it a bit more before deciding on my own middle ground