Overview of a Hanami 2 App Structure

Hanami really pushes the concept of abstraction or separation of concerns to the limit.

If you are coming from a Rails background and it feels a bit confusing, the simplified diagram below shows you how that abstraction is done in Hanami vs. Rails.

Routes

The Hanami router and its Rails counterpart are generally the same. They both recognize URLs and dispatch them to their relevant actions (in Hanami) and controller actions (in Rails).

Actions vs. Controllers

Instead of having controllers with actions in them, Hanami’s abstract style features bare actions, which are not encapsulated in any sort of “controller”.

“Models” vs. Models

Whereas you have models as the persistence interface in Rails, Hanami utilizes ROM architecture, which gives you repositories, relations, and entities. You also get “contracts”, which act as your app’s validation engine.

Views

In Rails, views are generally composed of the actual views, layouts, and partials. Hanami uses DRY view to abstract away this functionality into views, parts, and templates.

There’s obviously a whole lot more to Hanami’s abstraction style, and so to learn more, we recommend visiting the project’s website

Now that we have a general idea of what Hanami looks like under the hood, let’s keep going.

Step 3: Creating and Viewing Blogs

The image below shows how a simple http GET request is handled by Hanami.

We’d like to create a few blog articles and be able to view them, so we’ll start from the router and continue all the way to structuring the view.