On November 25th/26th, Luca, Piotr, and Tim met to discuss the current state of Hanami 2.0 development. Here’s a summary of the discussions:
Remaining areas of Hanami 2.0 work
We identified the following as the remaining broad areas of work for Hanami 2.0, and assigned each for someone to lead:
- Core application/slices polishing - Tim
- Continued application configuration polishing - Tim
- Zeitwerk integration - Tim
- CLI & generators - Luca & [?] (extra support would be helpful)
- Model/persistence layer - Piotr & Marcello
- View helpers - Luca & [?] (extra support would be helpful)
- Simple front-end assets integration via hanami-assets - Luca & extra support for webpack
- Interactor (or equivalent), backed by dry-rb gems - Piotr (we consider this is a “nice to have,” it could come last)
We confirmed the following are indeed out of scope for 2.0:
- An wide-ranging plugins/extensions API (though we’ll have some form of plugins to allow for
- Enhanced front-end assets integration using webpack, in separate hanami-assets-webpack gem (unless we can find help; see below)
Release timing & expectations
We’ll hold off on releasing the next alpha until the Zeitwerk integration is done. This is only weeks away, and it will mean we don’t have to communicate two different ways of loading internal code across the next two or more releases.
The next alpha should come out before the end of the year.
We can’t make any promises around the final 2.0.0 release, but sometime within the first half of 2021 feels realistic.
We’ll look to make more frequent alpha (and beta) releases after this next one, which will allow community members to follow the changes more closely. We’ll do these as soon as any discrete new features become available (e.g. model layer, CLI, further overall fixes/polish, etc.).
hanami-assets and hanami-assets-webpack
As part of 2.0, we’ll continue with the existing, simple approach of the hanami-assets gem, i.e. put an asset into a directory, allow references to it from the views, have the framework compress and fingerprint it at deploy time.
Along with this, we’ll look for help to build an enhanced hanami-assets-webpack that uses all the related modern JavaScript approaches.
Use of rom-rb directly vs an hanami-model wrapper
We’re likely to use rom-rb directly as the database persistence layer for Hanami 2.0. It already has the features we require and a helpful developer experience. Using it directly has a couple of additional benefits:
- Hanami users will not be locked out from rom-rb improvements arriving in rom-rb major version changes
- It demonstrates how our OSS organisations are working in alignment
However, there may be a need to keep hanami-model around as a very lightweight configuration shim around rom, supplying the configuration needed for a nice out of the box experience.
Decision: we’ll try using rom-rb directly first, and see how that goes.
Application/slices structure
The new slices structure is a divergence from the modularisation facilities offered in 1.0, and we had a brief discussion to ensure we’re all happy with how they’re working, and we are. Being able to modularise core business logic - not just the “delivery layer,” like controllers, etc., is helpful for growing applications.
Once we have Zetwerk in place, we can also consider whether Packwerk could be adapted for Hanami too, to further help with modularisation.
It would be helpful for us to include examples of various app and slice structures as part of our documentation, to help inspire people’s imaginations.
Application architectures & Hanami “micro”
Related to this, Luca wondered how we could incorporate a minimal application structure (an “architecture” in older Lotus/Hanami parlance), with code in lib/ and app/ only, using a single namespace, instead of spread across multiple slices with their own namespaces.
This approach would be helpful for teams that are extracting small pieces of functionality from larger applications, rather than aiming for a modular approach in service of a large or growing application.
We discussed how this organisation structure could already be achieved with the Hanami 2.0 framework already, which auto-loads all of lib/ dy default into its own “application” container. So by deleting the slices/ directory, you’ve already got yourself a single-namespace “micro” application.
To further support this use case, we’ll also do the following:
- Move hanami-controller and hanami-view (and hanami-router?) out of the gemspec and into the generated
Gemfile, allowing users to remove them if they want a stripped back Hanami experience. Some further work will be required to make sure there are no hard-coded or implicit dependencies on these within the core framework code. - Also include hanami-api in the generated Gemfile to allow people to define inline routes like this, for minimal applications: https://github.com/hanami/api/pull/20
- Make it possible to easily configure additional directories for code loading, like
app/ - Ensure the CLI code generators work just as well for generating code into
lib/andapp/as they do for slices.
Ruby version support
We’ll be officially supporting 2.6+ for Hanami 2.0.
So for now, this will mean removing JRuby and Truffle from Hanami’s CI; we can’t feasibly provide official support with our limited time and resources. It may still remain possible to run Hanami apps using JRuby, we just won’t be testing for it in CI. We’ll be happy to accept community help to restore full support for these implementations in the future.
CI setup
We’ll be moving to consolidate around GitHub Actions only, running MRI 2.6+. Luca may continue to use custom Docker images for tests to ensure we keep a stable environment.
Discourse as our preferred community engagement channel
We’ll stop recommending Gitter as a support channel, and instead encouraging everyone to use our Discourse forum.