00:00:04.640
Our next speaker comes from Moscow. He is an indie developer and a contributor to Hanami and Sidekiq. Please welcome on stage, Anton Davydov.
00:00:21.829
It's my first English talk in my life, and that's why I am really nervous about it. Anyway, hello to everyone.
00:00:31.070
It's my first EuRuKo and my first time in Sofia. I am happy to be here with you. I have met so many amazing people, and you are all so awesome. Thank you.
00:00:43.980
My name is Anton. I love stickers and open-source projects. I am also a Sidekiq and Hanami committer. You can find my commits in projects like Ruby on Rails and Crystal, among others.
00:01:01.620
In addition to my technical work, I am an organizer of the Moscow Ruby User Group, and I manage a Twitter account for Russian-speaking developers. This account is called @RuRuby, and it focuses on Ruby. It resembles an 'Ask Me Anything' format, similar to discussions on Reddit.
00:01:16.460
In Japanese, there is a beautiful concept called 'Hanami,' which means watching the blooming flora. The most popular flower is Sakura, but other flowers, such as tulips, are also appreciated. Today, however, we will focus on Ruby and not on flowers.
00:01:36.090
We will talk about Hanami, the Ruby framework. It was created by a developer from Italy named Luca. The first commit was made three years ago, showcasing that this is a very young framework.
00:01:55.710
The core team consists of two people, Luca and me. Let's start by discussing the general ideas behind this framework.
00:02:20.230
The first idea is modularity. It allows you to switch out any components of your view framework. For example, if you want to use Active Record or maybe ROM instead of Hanami's model, you can do so without any issues, and you can remove parts of the framework easily.
00:02:43.750
The next idea is simplicity. Simplicity helps provide a faster way to create production applications. This framework is just a tool and should not dictate how you code.
00:02:58.709
It employs a few conventions, allowing more freedom in structuring your applications. You do not need to worry about how to mix your business logic and the framework’s conventions cohesively.
00:03:24.940
Next, there is no monkey-patching, which is crucial for this framework. If you are familiar with where methods were defined in Ruby or Rails, monkey-patching can create complications. With Hanami, you won't face those issues.
00:03:39.519
Lastly, it is thread-safe, which is essential for concurrent programming or when developing web servers. Now, please note that Hanami is not the same as Rails; they are different frameworks that use the MVC pattern.
00:04:01.569
Any web application consists of two main parts of logic. The first part is business logic, which involves your model, database, and various calculations. The second part is data flow, which pertains to handling requests, invoking business logic, and responding to clients.
00:04:25.510
Let's delve into data flow in Hanami. The framework splits the logic across different paths. I want to refresh your memory about some great recommended practices, such as the monolith-first strategy. Hanami simplifies creating monolithic applications.
00:04:41.289
When you generate a new Hanami application, it provides an application folder containing several files divided into three groups. The first group is the configuration files; there is only one configuration file. The second group consists of routing and controllers, while the last comprises view paths, including view objects, templates, and assets.
00:05:07.150
As modern developers, we prioritize the SOLID principles in our work. We aim to separate our logic into distinct applications. For instance, we can place admin logic in a different location rather than within the main web application.
00:05:30.320
Hanami offers a straightforward solution for this: the solutions are continuous. After generating an application, Hanami creates two folders: the admin folder, which contains all parts of your application architecture, and another folder for the web section.
00:06:01.810
Let's talk about business logic. Hanami uses a library folder for all business logic, typically divided into two parts: the configuration and mappings, and the model. The framework implements the repository pattern, which is crucial for shaped architecture, and thus we have separate repository and entity folders.
00:06:38.560
You can place any library code within the library folder; for example, I use it for the mailer, but it’s versatile enough for various purposes.
00:07:00.960
Now I stated that Hanami is a model framework. Let’s look at all the parts of Hanami. If you check the GitHub repository, you'll find ten different gems. The first five are the core of Hanami, which generates files and provides a common line interface, such as the router, which needs only to map paths to controllers.
00:07:35.200
The second five consist of validation, helpers, views, and mailer. It’s essential to discuss the differences between Hanami and Rails because their principles and tactics vary.
00:08:08.570
One common saying is that talk is cheap, so in the upcoming slides, I will show only code samples. Our first code example exhibits a typical Hanami application.
00:08:34.520
This application features a simple class with one public method, which returns an array of three elements. Hanami utilizes a class-based approach and maps this class to different routes.
00:09:01.200
The next example is a Sinatra application, which you might find clear to understand, and similarly, Hanami allows block notation, enabling you to write applications akin to Sinatra.
00:09:20.050
It is important to examine how Hanami's actions correspond to Rails actions, as they have distinct frameworks and realizations of the MVC pattern.
00:09:57.550
Starting with the controller, a typical REST controller is a class with methods designated for request handling. It's evident that controllers in DHH's Rails implement a similar approach.
00:10:19.600
However, Hanami allows for a more simplified structure. You can define a typical action as a class, and this action follows a service object pattern, signifying its unique design.
00:11:11.780
Next, moving on to the model, Rails uses Active Record to encapsulate validation, database logic, and more within models. Hanami balances using repository patterns, where an entity class handles the state of an object.
00:11:40.070
Hanami emphasizes a distinction between the entity model and the repository pattern, making it clearer when working with data.
00:12:10.920
For shared functionalities, I have a straightforward slide that illustrates methods across Rails and Hanami. You'll notice that Rails often uses monkey-patching, while Hanami develops distinct classes solely for helper methods.
00:12:46.690
Lastly, let’s discuss views within Hanami. It employs template views, with partials, along with model helpers. In your models, you can invoke view logic, and instance variables are initialized in controllers.
00:13:12.660
In Hanami, you can create a simple data class that can be utilized to fetch data, eliminating the reliance on instance variables.
00:13:41.460
Unfortunately, I am not particularly fond of the action feature, so I will leave that segment for your independent review.
00:14:06.991
Now, moving on to the pros and cons of Hanami, one significant advantage is that it embodies a no-magic approach. It allows developers to write straightforward and effective code without unnecessary complexities.
00:14:35.840
The toolkit also fosters best practices for developers, focusing on modularity and test-driven development (TDD). The framework encourages implementing industry best practices.
00:15:09.510
In addition to this, it is crucial to highlight the shortcomings. One concern could be related to writing unnecessary tests, especially for aspects like view objects, which generate dynamic content.
00:15:35.390
Sometimes, the code can become verbose, particularly when trying to build straightforward applications involving multiple action_handlers.
00:16:06.050
The current stable version is 0.8, and while improvements have been made, past issues with helper routing and other features can still linger.
00:16:43.490
Additionally, despite its significant potential, being a relatively newer framework means that many useful gems are missing. It lacks additional integrations found in older frameworks.
00:17:43.470
Lastly, for modern developers wanting to work with cutting-edge technologies like WebSockets or React, Hanami might not currently support those features natively. However, you can certainly attempt to integrate such capabilities if you’re willing to adapt.
00:18:16.930
To wrap up, as much as we enjoy benchmarking, it’s important to recognize that not all benchmarks accurately reflect real-world scenarios. Nevertheless, I will share some benchmarks I performed.
00:18:50.240
For instance, in my first benchmark comparing Rack and Hanami, it was evident that Rack outperformed Hanami due to Hanami being essentially a wrapper around Rack.
00:19:05.690
A similar comparison was performed between Sinatra and Hanami. I created a straightforward JSON application that only returns a simple JSON response.
00:19:21.480
The last part of my talk highlights that Hanami is a relatively young framework. While some features are still in development, it provides innovative solutions to various problems.
00:19:56.420
If you want to explore more about Hanami, check out available resources and documentation. You can also contribute to the community.
00:20:09.500
This is the end of my talk. Thank you very much! If you have any questions, feel free to catch me after my talk.
