With Rails on Jets, what’s happening is Jets starts up a rack subprocess that runs the Rails app. A wrapper Jets app is generated and deployed. Finally, the wrapper Jets app proxies to the rack subprocess. So Jets Afterburner is really just a proxy to a Rails Rack app.
Generally, running a Jets application will give you the full power of Jets. Some examples: Jobs, Events, and IAM Policies. Though Afterburner mode is mostly transparent from a user perspective, there’s the obfuscation with the rack subprocess. This Mega Mode Post may be interesting to you also.
If you really need a full Rails application, you may be better off running Rails on traditional ECS just in case you run into AWS Lambda limits. I cover some of the Lambda considerations/limits in a presentation in Belarus: RubyConfBY 2019: Ruby Serverless Framework FWIW, am the author of a tool that helps with ECS Deployments: UFO ECS is a fine solution also. Think that serverless limits will fade over time.
Generally, recommend going with just Jets if the application can work with serverless. Decided to note on the Jets docs that Jets Afterburner is an experimental feature. Actually ended up fixing an issue in answering this question. Also, added some docs on this at the bottom “Rails with Jets vs Straight Jets” http://rubyonjets.com/docs/rails-support/
Hope that helps.
