A First Have a look at Hanami 2 for Ruby

As of at present (06/12/2022), Hanami 2.0.1 has been launched. Learn extra concerning the enhancements, bug fixes and gems in launch 2.0.1.

Hanami 2 was launched on 22 November, concluding 4 years of labor on this model. It brings a breath of contemporary
air into Ruby’s net growth group. Model 2.0 is not only an incremental improve. One may say it is a undertaking
written anew, with shiny concepts from model one rebuilt on high of a strong dry-rb libraries ecosystem.

Since there isn’t a clear improve path from model 1.3, on this article, we’ll concentrate on some key features of the discharge fairly than evaluating the 2 variations.

We are going to take an in depth have a look at the next:

• Slices
• Dependency administration
• Efficiency

Let’s get began!

Slices in Hanami 2

Hanami’s go-to answer for setting boundaries between completely different
contexts of a rising software is slices. By offering separate namespaces, slices make clear which code belongs to which
space and when the boundaries are crossed.

Notice that, as helpful as they’re, slices are additionally fully optionally available. In case your app is easy or you do not but know what
slices will emerge, you may simply put your code underneath a “foremost” slice within the app listing.

A brand new slice may be created inside an present Hanami software utilizing a CLI generator:

> hanami generate slice accounts
Up to date config/routes.rb
Created slices/accounts/
Created slices/accounts/motion.rb
Created slices/accounts/actions/.hold

This produces a really bare-bones construction underneath the slices subdirectory, with an Accounts::Motion superclass and a
listing the place account administration actions can be created. These lessons will, by conference, inherit from
Accounts::Motion. By doing so, they achieve behaviors particular to the applying’s person account space.

It’s possible you’ll marvel what “actions” are, precisely. They’re Hanami’s tackle organizing net endpoints. In Rails,
a controller class teams a number of actions (represented by public strategies). Nevertheless, in Hanami, you create one class per
motion. So an motion is a standalone unit of code that may be examined in isolation and fairly clearly states
what it does.

Let’s take a look at an instance motion class:

class Accounts::Actions::UpdatePassword < Accounts::Motion
  embrace Accounts::Deps["commands.change_password"]
  earlier than :require_authenticated
 
  params do
    required(:current_password).crammed(:str?)
    required(:password).crammed(:str?, min_size?: 8)
  finish
 
  def deal with(req, res)
	if !req.params.legitimate?
	  res.standing = 422
	  res.physique = req.params.errors.to_h.be a part of(", ")
    elsif change_password.name(
	    req.session[:current_user],
		req.params[:current_password],
		req.params[:password])
      res.standing = 201
      res.physique = "password up to date"
    else
	  res.standing = 422
	  res.physique = "can't replace password"
	finish
  finish
finish

Right here we now have all the data in a single place:

• The motion depends upon a change_password command
• It requires an authenticated person context
• It wants two parameters to be handed (and one among them should be at the very least 8 characters lengthy)
• Lastly, we now have a deal with methodology that holds the core logic of the endpoint: checking the validity of the params, calling a
  dependency, and setting an acceptable response

You is likely to be questioning what this syntax means:

embrace Accounts::Deps["commands.change_password"]

This brings us to our subsequent part about dependencies.

Dependencies

Accounts::Deps is a dependency mixin for the accounts slice. Hanami makes a dependency between completely different lessons
a first-class citizen.

As an alternative of getting dependencies hidden within the code, you may (and will, if you wish to comply with Hanami
philosophy) outline them on high of the category. Not solely does it make clear what you depend on, however it additionally makes the category simpler
to check.

Within the instance above, the “change password” command is outlined in slices/accounts/instructions/change_password.rb
as an Accounts::Instructions::ChangePassword class. The dependency mixin will make an occasion of it accessible as
change_password within the class the place you employ it. That is all primarily based on
dry-system.

In assessments, you may stub the dependency simply utilizing a built-in stub methodology:

Accounts::Container.stub("instructions.change_password", FakePasswordChanger.new)

If, for instance, your authentic command makes use of a slow-by-design hashing algorithm (resembling bcrypt), you may swap it
with one thing sooner in assessments.

Nice Efficiency in Hanami

Talking of efficiency, Hanami is quick. It boots actually quick as a result of suppliers are solely booted
when wanted, not eagerly on the software begin. Consequently, a hanami-reloader gem (used to
reload an software after modifications are made to the code in growth) does not want a complicated and
fragile reloading mechanism. As an alternative, it simply reboots the entire app in milliseconds. Easy but efficient.

However there’s extra on this entrance. Hanami 2.0 features a brand-new router, which makes it
sooner than Sinatra, Grape, and Rails in benchmarks.
Which may not be crucial indicator for a database-heavy net software, however it’s value noting.

Hanami actions themselves may be very speedy as properly. As an anecdote, a number of days earlier than the ultimate launch, Peter Solnica
from the core workforce tweaked a logger to show the time it takes
to course of a request in microseconds as a result of he was getting sub-millisecond occasions.

What Is not in Hanami 2 (But)?

Earlier than you begin to rewrite your foremost software in Hanami, you need to hold a number of issues in thoughts.

Model 2.0 is a bit stripped-down. As of at present, the framework doesn’t have a default view
and database layer. Nevertheless, individuals report that including the previous is simple with the hanami-view gem, which is sort of prepared.
The persistence layer may be applied utilizing ROM.rb.

Official help for the lacking items is deliberate within the Hanami 2.1 launch.

My Private Expertise with Hanami 2

I’ve had a take a look at Hanami software for the reason that beta 1 launch. It’s a plain previous server-rendered dialogue discussion board – assume one thing like phpBB. The app checks how a lot effort it takes so as to add widespread options to a Hanami software, resembling
person authentication, file uploads, and so on.

My expertise to date has been optimistic. Pre-2.0, I reported some points to the maintainers. They had been tremendous useful and the problems had been rapidly fastened.

Basically, though the Hanami ecosystem lacks any “plug-and-play” options resembling Devise, you need to use many
present libraries not tightly coupled to Ruby on Rails. For authentication, you need to use
Warden, OmniAuth or
Rodauth. For uploads there’s Shrine. The pagination
is constructed into ROM. Integration with exception catchers resembling
Rollbar is simple.

To this point, I have not hit any obstacles that might block me from progressing.

Wrapping Up

I’m excited concerning the future and ready to see what Hanami 2.1 will deliver when it comes to views and persistence.

The Ruby
group hasn’t actually had a couple of feature-complete full-stack net framework since Merb, so it’s actually
refreshing to see a change in that space.

Glad coding!

P.S. If you would like to learn Ruby Magic posts as quickly as they get off the press, subscribe to our Ruby Magic e-newsletter and by no means miss a single put up!