3 ms·

Hono looks very cool but in my experience you can quickly run out space in your lambda (package size) when you bundle your whole application together verses hav

Hono looks very cool but in my experience you can quickly run out space in your lambda (package size) when you bundle your whole application together verses having each endpoint be it’s own package. Am I wrong or have others experienced this as well? Just having 1 package (to deploy vs 1 per endpoint) would be super nice in a number of ways and you could take advantage of things like provisioned concurrency (something much more difficult to plan for when you have a lambda per endpoint). Maybe I’ll just branch my main project and see what happens as I move my code into a monolith with Hono but I’d love some feedback if others have experienced this and/or how they worked around it. I guess you could still have multiple Hono-based packages that handle segments of your backend (verses all in one), is this how people are managing it?

willsmith72 3y ago
how much space is too much? curious how much you've had hono apps use i've done a few express apps on lambda, just because it was a free way to host fun projects and i didnt want to use a custom framework/tech, and they never got above 25MB zipped. big, but not really close to the limit (i believe 50MB)
- joshstrange 3y ago
  I’ve never used Hono, I’m just interested in it. I think the AWS Lambda limits are something like 50Mb compressed and maybe 200Mb uncompressed. I might be a little off, I’m on my phone right now. Prisma doesn’t help matters but right now I take that hit on every function package anyway. I might just need to try it one day (move my existing app to Hono to see if it would work).
toinbis 3y ago
Am very curious about the same very question. "I guess you could still have multiple Hono-based packages that handle segments of your backend" -> I am thinking the same - if you hit bundle size problems, you can just split your app. I'd also love to see some benchmarks how bigger bundle size impacts the performance - i.e. 1 MB adds additional 1ms on average, or so... My platform of interest is mostly Cloudflare Workers.
bleeding 3y ago
I think with Lambda there are a lot of downsides to either approach. When you build the Lambda as a monolith, you also give all the code executing from that monolith access to all the resources needed by every single route in the Lambda. When I was working with Lambda a lot, we had a lot of secrets that were only needed by a few routes, and which would have been very bad if someone misused those secrets from a different place. But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs. I think there's a happy medium where you group lambdas by resource type or domain, but even still it can be tricky to enforce "least privileged access" for those when the content of the lambdas is constantly being added to. Eventually there is creep in the IAM permissions available to those lambdas. I came up with a system that did incremental build/deploys for all of our lambdas based on the code changes since the last builds/deploys, but even so that came with some pain and definitely some hacks that I wouldn't do again (and relied on technologies it was difficult to get other people to engage with, like Bazel.) I also think Lambda (in particular of the FaaS options) is...not great for APIs, especially if you use a language with a long cold start time.
- joshstrange 3y ago
  > But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs. Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster). I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want. I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high). [0] https://sst.dev https://sst.dev

willsmith72 3y ago

how much space is too much? curious how much you've had hono apps use i've done a few express apps on lambda, just because it was a free way to host fun projects and i didnt want to use a custom framework/tech, and they never got above 25MB zipped. big, but not really close to the limit (i believe 50MB)

joshstrange 3y ago
I’ve never used Hono, I’m just interested in it. I think the AWS Lambda limits are something like 50Mb compressed and maybe 200Mb uncompressed. I might be a little off, I’m on my phone right now. Prisma doesn’t help matters but right now I take that hit on every function package anyway. I might just need to try it one day (move my existing app to Hono to see if it would work).

toinbis 3y ago

Am very curious about the same very question. "I guess you could still have multiple Hono-based packages that handle segments of your backend" -> I am thinking the same - if you hit bundle size problems, you can just split your app. I'd also love to see some benchmarks how bigger bundle size impacts the performance - i.e. 1 MB adds additional 1ms on average, or so... My platform of interest is mostly Cloudflare Workers.

bleeding 3y ago

I think with Lambda there are a lot of downsides to either approach. When you build the Lambda as a monolith, you also give all the code executing from that monolith access to all the resources needed by every single route in the Lambda. When I was working with Lambda a lot, we had a lot of secrets that were only needed by a few routes, and which would have been very bad if someone misused those secrets from a different place. But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs. I think there's a happy medium where you group lambdas by resource type or domain, but even still it can be tricky to enforce "least privileged access" for those when the content of the lambdas is constantly being added to. Eventually there is creep in the IAM permissions available to those lambdas. I came up with a system that did incremental build/deploys for all of our lambdas based on the code changes since the last builds/deploys, but even so that came with some pain and definitely some hacks that I wouldn't do again (and relied on technologies it was difficult to get other people to engage with, like Bazel.) I also think Lambda (in particular of the FaaS options) is...not great for APIs, especially if you use a language with a long cold start time.

joshstrange 3y ago
> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs. Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster). I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want. I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high). [0] https://sst.dev https://sst.dev