Hacker News Reader

Comment by joshstrange | Hacker News Reader

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?

View on HN

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.

> 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

Nice, we evaluated their Seed product but didn't pull the trigger, which caused me to eventually roll our own. I'm pretty proud of what we ended up with but due to reasons we ended up with _hundreds_ of lambdas, for which a full re-build re-deploy took around 45m (Go lambdas).

We used Go and the Serverless framework (ugh), and if I had to do it all over I would probably just use AWS SDK since it would make doing the "diff" to redeploy dead simple, since everything is just a binary to build.

Your use case definitely makes sense for Lambda APIs though! I think my complaint is more directed at APIs that back frontends. We had a JVM lambda API there for a while that was horrificly slow startup unless you set provisioned concurrency, which gets expensive fast.

Yeah, I totally understand and agree with your "downsides" for lambdas. My use case just happens to gel perfectly with them but it's not a "one-size-fits-all".

I also looked at SEED and I would like to give them money but some of their methodology with SEED didn't fit with mine and since my deploys aren't horrible I left my system as-is. Also I understand they need to make money but I wish more tools geared towards serverless "scaled to zero". I'm happy to pay but my company has such bursty traffic that paying for a plan (on SEED or something like monitoring) that can handle our "peak" means burning money 70%-90% of the time while our app is scaled to zero but we still have to pay for tools around it.

Some monitoring tools, like New Relic, are based on usage but both NR and DataDog have absolute shit serverless monitoring solutions and their docs are a dumpster fire (at least around serverless). It's also unfortunate that most serverless monitoring means adding ~$10 per account per month (in increased AWS costs) just for their data pipelines to scan CloudWatch logs. This again sucks since we have an AWS account per client but each client is only active for ~1mo every year so it can get expensive fast.

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.

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)

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).

Reply on news.ycombinator.com