Investigate whether Thruster is useful for us

[eoinkelly]

https://github.com/basecamp/thruster/ is installed by default in vanilla rails new from 8+ onwards. Does this have a use-case for us?

[eoinkelly]

I think this is an idea worth exploring but I don't think I need to block the Rails 8 upgrade on it. I'm removing the Rails 8 label.

[joshmcarthur]

So, feature set on this:

• HTTP/2 support
• Automatic TLS certificate management with Let's Encrypt
• Basic HTTP caching of public assets
• X-Sendfile support and compression, to efficiently serve static files

All of these other than automatic TLS management we'd get value out of. HTTP/2 seems to be supported by ALB, but it's lumped in with gRPC so it's not 100% clear.

It's worth noting that in environments where we wouldn't be using ALB, Thruster can take over the role of terminating public traffic. I can't think of any situations where that exists at the moment where another load balancer isn't already in the mix, but it's good to know for small apps.

The downside is mostly that it's something else on our critical request path that we need to be aware of, and potentially debug. I've personally had debugging instances where I'm had to swap thruster out to directly invoking puma, just to check that thruster wasn't interfering with a particular issue (it wasn't). Worth thinking about.

This sort of thing is much less of an issue with Docker deployments IMO, because changing our entrypoint or CMD is in code, not provisioned. This makes it easier to perform upgrades, differential diagnosis, etc.