Support for Rack compatible apps other than Rails

[svoop]

Kuby is a very nice piece of work with support for different cloud providers – including the ability to add your own provider.

The other end, however, appears to be less flexible: According to the docs, «Kuby is designed to work with Rails 5.1 and up». It would be very cool if Kuby supported any Rack-compatible app (such as Hanami, Sinatra etc) as well, maybe using a modular approach similar to the provider end.

Is this in any way desirable and feasible?

[camertron]

Hey @svoop, that's a great question. Kuby was designed to work with Rails, but most if not all of the Rails functionality is encapsulated in the :rails_app plugin. We could semi-easily support other web frameworks by creating additional plugins. Here's what would need to change:

1. There are a few parts of the code that expect the :rails_app plugin to exist. We'd have to add some nil guards to prevent things from exploding.
2. I'm not super familiar with how Sinatra, Hanami, etc handle things like static assets, database access, etc. In Rails, all that stuff is baked in, so Kuby can make a lot of assumptions. We would need to ask the community for input and decide how to solve those problems for a general audience.
3. Kuby doesn't really have the concept of Docker plugins yet. I imagine there would be some similarities but also some significant differences between building a Docker image for a Rails app vs building one for Hanami or Sinatra. All the pieces are there, it's just a matter of wiring them all together. For example, dev environments are built from Docker::DevSpec - we could have a Docker::HanamiSpec as well... or something.

[svoop]

@camertron

This is certainly one of the situations where the predictability of Rails comes in handy. However, even with Rails, such assumptions may not apply e.g. when Faucet Pipeline is used instead of Sprockets or Webpacker. As for Hanami, it's a much more modular framework – you might use the Hanami model gem or assets gem, however, you're free to do things differently.

Quickly skimming over the :rails_app plugin, there's quite a bit of code e.g. to create the Nginx config for static assets. Maybe there's a way to introduce a framework-agnostic configuration layer which holds everything Kuby needs to know in order to deploy a Rack-app. The Rails plugin could then preset this configuration layer based on assumptions. (By focussing on this task, the plugin should have way less LOC compared to now.) Similar plugins for other frameworks could guess based on common practice. And once the plugins are done, incorrect assumptions or guesses could be overridden by explicitly setting them.

I'm sorry if this is a naïve view, I have to admit that my knowledge of Docker and Kubernetes is rudimentary as of now. Other folks may have more expedient ideas to share than me.

[camertron]

@svoop right, these are all good points. There's no way I'm going to be able to anticipate all the different configurations out there in the wild, so it makes sense to provide ways to turn things on and off. I'm just not familiar enough with the Hanami and Sinatra communities to know what the defaults should even be, or how to architect the knobs and levers 😦

I think a feature like the static asset server wouldn't need to change too much, since I assume for Faucet, hanami-assets, etc there's a compile step that produces a set of static files just like there is for webpacker and the asset pipeline. The Kuby asset step during deploys just copies the static files from your Docker image into the asset server so nginx can deliver them.

I think database access, webserver configuration, secrets, etc are going to be the most problematic features.