feat: Switch to Rack + Roda and away from Webrick

[jaredcwhite]

As part of the push towards Rails API Ruby backend integration, it's become clear to me we need to remove our dependency on Webrick and retool around Rack (and Puma as the actual server). And not just Rack alone but a routing layer which can sit just above it—a good solution being Roda.

This would provide a number of benefits:

• The only use case currently for Webrick is local site development/testing. Webrick isn't recommended for any production use. While Bridgetown typically is a build-and-deploy solution (hence the Static Site Generator moniker), there are reasons why running Bridgetown "live" through a web service could be desirable.
• Furthermore, by making Bridgetown essentially a Rack app, it not only makes integration with an API easier, it allows Bridgetown itself to enter the realm of true all-in-one web framework…with the ability to handle a pretty seamless range of SSG & SSR needs.
• Alternatively, if you already have a Rack app/Rails/etc., you could "bolt" Bridgetown on as a sub-path, just like any number of other apps (like how Rails apps can incorporate Sinatra apps such as Sidekiq's admin UI).

My initial preference to start would simply be to swap Webrick out for Rack/Puma and otherwise keep all features and CLI options as much the same as possible. Then we can assess where to go from there.

Feedback most welcome!

[ayushn21]

I'm 100% behind the idea of swapping out Webrick for Puma or similar. Though I don't quite understand why we'd want Bridgetown to be an all-in-one framework.

I'm just wary of losing a degree of focus and simplicity by stretching ourselves too thin and attempting to solve too vast an array of problems with Bridgetown. The way I see it, keeping Bridgetown as a build-and-deploy solution keeps the focus of the project strong.

Combining Bridgetown with a first-class integration with Rails (which has one sole purpose of being a rock solid web framework) would in my opinion fulfil any use case that running Bridgetown live thorough web service would.

Just my $0.02.

What do you think the advantages of taking Bridgetown into the realm of an all-in-one framework would be?

[jaredcwhite]

What do you think the advantages of taking Bridgetown into the realm of an all-in-one framework would be?

I'm probably getting ahead of myself here…the primary use case I'm thinking of is being able to do a live rerender of a particular URL, maybe pass some request params along. Not trying to compete directly with Sinatra/Rails/etc. But thanks for the reminder we shouldn't try to dilute the value prop of the technology.

[ayushn21]

Yeah haha it's so easy to let the brain charge ahead! I agree a great first step would be to swap in Puma and then we can take it from there!

[jaredcwhite]

FYI — did a ton of local benchmarking between Puma and Falcon for both Roda and a Rails nano project, and Puma with 8 threads + 16 workers beats all. Roda + Puma with a simple {"hello": "world"} response even gets within spitting distance of Fastify, one of the fastest Node.js server frameworks in the business! (~10% delta)

Server	Avg Req/Sec	Avg Latency	Max Latency
Roda/Puma	57147	17 ms	117 ms (although I once got as low as 89ms!)
Fastify	63077	15 ms	101 ms

Benchmarked via autocannon -c 100 -d 40 -p 10 http://0.0.0.0:9292 on my MacBook Pro 16" 2.3 GHz 8-Core Intel Core i9 w/16BG RAM

Roda on Ruby 3
Fastify on Node 14.3

[jaredcwhite]

This is part of the v1.0 alpha now!