Bummer. Yup. AWS has limits like any other cloud provider.
As you mentioned, Jets 3.0.17 has rate-limiting improvements. Actually ran into rate-limit issues issue enough with a BoltOps client that has over 200 lambda functions. Fixed it as a part of that work. They haven’t seen or reported any more rate limit issues since then. So believe address most of the rate-limit issues for large apps.
RE: It would be a nice option, if all actions (GET, PUT, etc) on a given resource (/foo/bar) could be deployed to a single lambda rather than a separate lambda for every action.
No current way to do that with a framework setting. Would consider PRs but unsure how that would work right now.
If you want to combine things into a fewer or single lambda function, here are some approaches:
- One away is to each of the controllers to catchall controller action routes and then within the controller delegate to private methods or other classes or some pattern that makes sense for your app.
- Another way is to have an
AllControllerthat handles the catch-all route. That can then delegate to other ruby classes to handle your needs. This will only generate 1 lambda function and you are delegating to the rest of your app logic. - Another possible way is to have a rack compatible app and mount it: https://rubyonjets.com/docs/rails/mount/
There will be some rework to your app structure, but those are some approaches.
RE: significant cost increase in our lambdas
Sadly, unsure what’s going with that. Debugging it a bit and couldn’t reproduce it: UPDATE_FAILED AWS::CloudFormation::Stack JetsPreheatJob Embedded stack