by default, Hanami comes bundled with puma - and rightly so, as puma is pretty dominant in the space.
but, in keeping with the philosophy of modularity and developer choice that Hanami brings to the table, I think that providing some options in what web server your app runs on could be a valuable addition to the framework and help set it apart
the server selection would happen when generating a new app, and of course be opt-in. something along the lines of:
hanami new my-app --server=different_server
to start, i believe this could be a helpful way to provide some default configs for the developer, instead of having to retroactively change an existing application.
this could even lead to future efforts to continue expanding Hanami’s offering and personalization. for example, Hanami curated tools / bindings of server specific features
i would be happy to tackle this feature, if everyone deemd it worthwhile of course
I’m open to something like this, but wary of the potential support burden.
For example, I think it would be cool if we could make Hanami works nicely with falcon and take advantage of its unique async features, though that may be a larger project than just generating a single different config file in new apps.
So, why am I wary? Because if we officially support n webservers, then that’s n different things we’ll need to properly test in order to make sure we’re providing the right experience to people
That said, I think we could get to a place like this! But there’s a few steps we need to take first:
Someone needs to figure out the setup for one of these different web servers, then run it in production and verify that it performs as expected.
Then we can share that setup as a “recipe” — we can blog it, and at some point even create a section in our guides about it.
After that all goes well, we can then consider building it into the official app generator.
So you could totally do (1) and (2) now, @Kyle, if this is something that’s personally interesting to you.
There’s also another technical task that’s related: Rack 3 support! We don’t have it yet. And I’d really like us to have it. I tried it briefly in the lead up to 2.0, and it caused just enough tests to fail that I decided to put it in the “do it later” basket. Well, I reckon we’ve definitely arrived at “later” by now! So if upgrading to Rack 3 sounds interesting to you, I’m very happy to support you in that endeavour too.
I hope this response is helpful! I’m sorry it couldn’t be an outright “yes, let’s do it!”, but I hope you can understand my reasoning here. While our team is small, I want to make sure we can streamline our support and testing responsibilities too.
falcon was actually the where this idea originally stemmed from! I feel as though there is a fair amount of overlap in philosophy between hanami and falcon, and there could potentially be a pretty neat marriage there
that being said - i completely understand and sympathize with your reasoning. to add to it, (1) and (2) could even be a good way to gauge community interest. no point in spending time on something nobody wants! I would be happy to start there
also - Rack 3 might be a great stepping stone in this general direction. while I dont have a ton of experience with this slice (lol) of the stack, it’s something i’m personally interested in learning more about and would be happy to take a stab at adding this support! I’ll open a PR once i have something worth reviewing
