What's really special about Jets in particular is it lets you have your cake and eat it too, in that locally you have what feels like a pretty normal monolithic Rails app, but when you deploy every endpoint magically becomes its own lambda...
To be fair that’s exactly what NextJS does too. In dev everything runs locally, when you deploy to Vercel or a similarly capable host each non-static route becomes a lambda.
He says quite clearly in the GP. It solved all their scaling problems and massively reduced their costs. With a note that their traffic was particularly bursty.
Does the “lambda per api endpoint” part help with the application boot part or something? Otherwise I don’t quite see what advantage you would with that get over just one lambda for the entire monolith.
OC also mentions that they run a job to keep the lambdas warm. One disadvantage with the lambda per endpoint is that he has to keep dozens of lambdas warm instead of just one.
Dead code/dependency removal. "Tree shaking". If you only serve one route per lambda, you can be (somewhat) sure about what you need and compile the minimal optimized code path for that.
Less "stuff" in each route, less boot/warmup time for each lambda.
I tend to agree that in a lot of cases just sticking the whole monolith in a single lambda is fine, and that's probably how I would do it if I had to do things manually. But as things grow, it becomes much better to tree-shake unused routes, though dead code detection in Ruby might as well be a pseudo-science with all that Ruby can do lol
