We took a step forward by dropping WEBrick for Puma, and I think we should take this further and remove this hard dependency as well. Roda is a Rack-compliant framework and there's no technical reason why we need to depend exclusively on Puma.
We can add compliance to Rack in general and have a sensible Puma setup out of the box, but if someone wanted to bring their own server, they should be able to.
Motivation
This is a result of an ADHD fuelled deep dive into Rack 🤣. These two talks led me down this rabbit hole:
Falcon is a new Rack compliant web server built on top of the Async gem. This makes it easy to write heavily concurrent apps, as long as the performance bottleneck is with IO. Puma uses threads and waiting for server side API requests to come back would hold up the thread meaning it couldn't serve other requests. This could be a problem on small deployments.
Falcon uses Ruby Fibers for each request which are very cheap and the Async gem is very efficient at switching between them when they're blocked by IO. I think this might be a great option for Bridgetown somewhere down the line.
In any case, I think folks should be able to choose any Rack server since live deployments of Bridgetown are also now possible, and the server isn't just for development.
Reference-level explanation
We can use the rackup gem to start a generic Rack server in the start command. Since Puma is already Rack compliant, I don't foresee any huge problems with this.
We should also bump our minimum Rack requirement to v3. Without a massive legacy, I don't see why we shouldn't. Rack 3 added native support for bi-directional communication. This was quite hacky to do in v2. Rack 3 also makes significant architectural changes wherein rackup was broken out into its own gem. It would be cleaner to just go all-in on v3 instead of trying to support both.
Since Bridgetown is primarily used in static deployments, I don't foresee any issues with this. Even for users of live deployments, the change should seamless.
Falcon is also a fully Rack 3 compliant and HTTP/2 compliant server making it a viable option for folks who would like to use it.
Summary
We took a step forward by dropping WEBrick for Puma, and I think we should take this further and remove this hard dependency as well. Roda is a Rack-compliant framework and there's no technical reason why we need to depend exclusively on Puma.
We can add compliance to Rack in general and have a sensible Puma setup out of the box, but if someone wanted to bring their own server, they should be able to.
Motivation
This is a result of an ADHD fuelled deep dive into Rack 🤣. These two talks led me down this rabbit hole:
https://www.youtube.com/watch?v=x8qOIY252sw https://www.youtube.com/watch?v=yXyj9wlkJKM
Falcon is a new Rack compliant web server built on top of the Async gem. This makes it easy to write heavily concurrent apps, as long as the performance bottleneck is with IO. Puma uses threads and waiting for server side API requests to come back would hold up the thread meaning it couldn't serve other requests. This could be a problem on small deployments.
Falcon uses Ruby Fibers for each request which are very cheap and the Async gem is very efficient at switching between them when they're blocked by IO. I think this might be a great option for Bridgetown somewhere down the line.
In any case, I think folks should be able to choose any Rack server since live deployments of Bridgetown are also now possible, and the server isn't just for development.
Reference-level explanation
We can use the
rackupgem to start a generic Rack server in thestartcommand. Since Puma is already Rack compliant, I don't foresee any huge problems with this.We should also bump our minimum Rack requirement to v3. Without a massive legacy, I don't see why we shouldn't. Rack 3 added native support for bi-directional communication. This was quite hacky to do in v2. Rack 3 also makes significant architectural changes wherein
rackupwas broken out into its own gem. It would be cleaner to just go all-in on v3 instead of trying to support both.Since Bridgetown is primarily used in static deployments, I don't foresee any issues with this. Even for users of live deployments, the change should seamless.
Falcon is also a fully Rack 3 compliant and HTTP/2 compliant server making it a viable option for folks who would like to use it.
Drawbacks
I don't think there's any reason not to.