Move away from rails

[robbevp]

Considering some options to move away from rails. Might be good to explore the options in a separate comment. Some first options:

• loco (rust)
• axum (rust)
• hanami (ruby)
• brutrb (ruby)
• mosscap (ruby)

[robbevp]

Switch to axum (rust)
We could use axum as the web framework and diesel or sea-ORM as the ORM. I have good experiences with axum and diesel (though the latter can be frustrating to use at times).

Since this is more of a bare-bones setup, the following will be tricky:

• Handle assets as we do with active storage
• Background jobs: axum doesn't provide anything for this

[robbevp]

Mosscap
Probably the easiest change, but it will depend on whether this can be pulled off. It's likely that this would start without a fork of active job and active storage, so we'd still depend on rails for the time being

[chvp]

Loco

Just to mention it, but with the recent switch to LLM workflows, it doesn't seem like an option we'll want to switch to.

[robbevp]

Had a quick look at this, but their workflows and ways of releasing would make this a hard no from me

[robbevp]

BrutRB

I really like some of the ideas here (the way forms are classes, and each page/handler is its own class), but:

• This is mostly geared for full stack apps with SSR html (which we don't do)
• Currently no built-in support for assets or background jobs
• (Testing is only done with rspec)

[chvp]

Yeah, I came to the same conclusion when I looked at it. The focus on SSR html makes this a non-starter IMO.

[chvp]

Hanami/Hanakai

As far as I can tell, there's no first-class support for background jobs or an equivalent for activestorage.

It's not obvious to me from the docs whether there is support for rendering JSON in the views.

[chvp]

Phoenix

Rails-like framework in Elixir. No native activestorage/background jobs, but it's a mature framework with a number of surrounding libraries.

E.g. for background jobs I found rihanna from a quick cursory look and for activestorage-like I found waffle.