00:00:01.340
Okay, let’s try this. Can you show our Kiowa?
00:00:07.230
Thank you very much. You can see my email here; just send me something and I’ll send a lot of links because this is a longer presentation. Maybe you will miss something.
00:00:16.289
This is my second time in Japan, and I can say that I've learned many things, especially during this visit. I've gotten answers to some really important questions for me.
00:00:31.199
The first question is: Is Ruby still awesome? I can say yes, it is awesome. The second important question is: Is Java more popular than Ruby? Yes, it is. A very important question I will answer today is: Is Ruby dying? Of course not. And the last question: Is Rebecca still awesome? Yes, she is still awesome.
00:00:54.149
Thank you so much! I'm super happy to see you all here and to be here again. My name is Anton Davydov, and you can find my contact information here. I'm from Russia, which is very close to Japan—just an hour's flight away. You need to know two things about me: First, I really love stickers; I have a new laptop, that's why it's empty now, but maybe in the future it will be covered in them. Second, I really love open source and the ideas from open source.
00:01:29.189
A little announcement: This is a really big presentation, and I’ll repeat it again—send me anything to this email, and I will answer you with a lot of links from this presentation. Today, we will talk about architecture. I'm not able to see your architecture, but you can trust me.
00:02:06.390
The main reason for giving this talk is to share some ideas from Hanami projects. I've written many Hanami projects and I try to understand the best way to manage dependencies and business logic. I also want to get feedback from you, so if you want to discuss anything, please find me tomorrow, today, or on the last day of the conference and we can talk about problems because who doesn't love problems?
00:02:45.600
In my practice, each application or project in a company usually has three different technical problems: management problems related to deadlines and asset research, performance problems which may involve multiple SQL queries, and maintenance problems. Today, we will only focus on maintenance problems. Let’s talk about some interesting concepts you can find on the internet, which include clean code, good architecture, and maintainable projects.
00:03:41.280
Can someone explain what good architecture means? I think it's a complex topic because it’s difficult to define what clean, good, or maintainable really means. Therefore, let’s try to answer a simple question: What do we want in our system? We want to add new features and usually for adding features, we need some rules. Typically, this involves isolating logic and managing global state.
00:04:09.180
We also want to delete or refactor some features, which requires us to isolate certain parts of our project. This makes it easier to maintain just one part instead of thousands of lines of code. Additionally, we need to ensure we have test coverage. If we conclude all this, we can say that from a maintainable system we need isolation, controlled logic, and no global state.
00:04:40.220
Unfortunately, we live in a world where we have something like Rails. If you want, I can show you all the stats; it has more than 2 million lines of code. So how can we improve this situation? The first thing we need to understand is abstractions—because abstractions are everywhere.
00:05:02.190
We will start our discussion from actions. Some internet articles or books suggest that the MVC pattern is extremely clear and simple for maintenance and building. I agree with this because you write code with some view controllers and then you create the MVC pattern. Some solutions for this problem include functional objects. These can be anything, such as services, interactors, or dry transactions.
00:05:58.840
Can I see a show of hands for who has used dry transactions? Great! So what is it generally? It’s an object you create without any state. You call some methods with parameters, and it produces a result object that you can work with, without mutating any state. It ensures isolation for our project.
00:06:11.680
For example, in Hanami, when we work with actions, we see that we get a result, and then we operate with this result without issues. The functional object pattern also helps establish a clear sequence for logic, as evidenced in dry transaction examples from my project where we handle different steps: extract data, transform data, and create something new.
00:06:52.060
Moreover, functional objects eliminate global state. Every time you create a new instance, you call a method that doesn't mutate any data within your object. This focus on a non-mutable state makes testing easier. But to ensure your functional object is easily testable, you need to implement dependency injection.
00:07:11.680
So, who loves dependency injection? It’s important because we can inject different functional objects into our Hanami actions or any other object. This means in our tests, we can easily substitute a successful dependency with a failing one, ensuring our tests cover various scenarios. Additionally, we can use lambdas and procs, as they have call methods. Lastly, some objects can call other objects, such as interactors in Hanami.
00:07:45.900
However, we encounter issues with this pattern. Firstly, we have numerous objects, making it very challenging to manage everything. We need to use namespaces and scopes, which leads us to use lengthy names for objects. For example, we could have something like 'orders car and coupon operation'—that’s quite a mouthful. Additionally, every time you call a new functional object, you instantiate a new object which can negatively impact performance.
00:08:18.660
We can mitigate this by using containers, which leads us to the next abstraction: dry containers. Let’s talk about dry containers. Has anyone used them before? Awesome! The concept is straightforward: you create an instance of a container, register some dependencies with specific keys, and then call these dependencies by their keys to obtain their instances. For instance, in Hanami, when you call a method with some parameters, you can control global state more effectively without creating tons of constants.
00:09:24.620
This container also allows instance memoization for better performance, and testing becomes more manageable since you can create mocks for your container dependencies. The next abstraction we’ll discuss is dependency injection. Think of it as dependency injection on steroids. To use it, all you need is to create a new instance of your container, making it usable throughout your classes.
00:09:53.850
When you do this, you can add a method that initializes your dependencies and use them in various places throughout your application. Moving on to models, let’s first establish that the MVC as a pattern is incredibly simple. You just create a view and controller and add models; that’s it. However, we need to define that all business logic should reside in service objects and models.
00:10:15.080
Validation in models is a bad practice. Our models should simply be responsible for loading and persisting data. In the Rails community, I know that query objects are popular. So who uses query objects? In the context of Hanami, we have repositories. If you look at Hanami’s documentation, you’ll find descriptions of how to manage this more effectively for neat and organized logic.
00:10:49.300
For complex logic when you need to create, save, or update complicated entities, you can use change sets. But doing it this way might lead to callbacks that can create a complicated logic flow. For example, take a look at this code where a class injects user repositories instead of merging created information into the payload directly. Using change sets allows you to manage this effectively.
00:11:38.550
Now, let’s talk about applications. This is my favorite part of the talk because in a previous job, I worked with Rails applications that contained models and services. Over time, I realized that we had two Rails applications sharing similar models and services while using the same database. To update any one application, we would also need to run migrations on the others, which created unnecessary complexity.
00:12:30.420
With Hanami, if you look at a typical application, you'll see that it can act as one project with shared business logic. This shared logic between different applications can significantly change your mindset. If you recall the earlier discussion about actions and interactors, you can easily transform that into applications that invoke business logic seamlessly.
00:13:54.890
In Hanami, you can start with just one application, which is crucial when you want to split your projects into different parts. However, we still encounter challenges. I recall a situation where a developer updated a mobile API but forgot to update the administration application. This caused a break in functionality, highlighting the importance of keeping track of changes across applications.
00:14:45.310
Sometimes, you might need to apply similar yet differing logic in various areas. We need to delve deeper, and a brief warning: we’re now entering an advanced level. You can build applications using all the previously mentioned concepts, but the next steps involve improving quality and maintaining project integrity.
00:15:39.600
The first new concept is a dry system. It’s essentially a dependency management system that can do two main things: after registering dependencies into a container, it operates similarly to Rails in managing the registrations and retrieval by specific keys. This makes it easy to handle dependencies without cluttering your code.
00:16:36.240
On the other hand, another helpful feature of the dry system is dependency booting. This allows you to create a specific register block where you initialize your application by checking connections to your database and managing dependencies in an orderly manner. This ensures a structured environment where all dependencies are well managed.
00:17:27.470
Next, let’s discuss domains. Love for DDD (Domain-Driven Design) is extensive, especially in Polish communities. If you want to understand why DDD is beneficial, I recommend checking out Martin Fowler’s book on the subject. The essence is that you can create separate domains for distinct business values.
00:18:17.360
For instance, a shopping application might have one domain for orders and another for users. Each domain is related to others, which allows you to create independent services that can easily communicate with each other. While creating an application structure under DDD could be complex, it opens up more manageable pathways for scaling your applications.
00:19:10.680
When looking at typical Hanami projects, you’ll note that each application can invoke various business logic, such as utilizing repositories or network clients effectively. The architecture allows for flexibility and independence, where applications can call different domains. HTTP is just a small portion of what your system comprises, as in real applications, you will likely interact with background processing, websockets, and much more.
00:20:07.560
This means that your business logic consists of different events. For example, when you create a user, you fire an event to notify that the user is created. When you process an order, you create an event to indicate that the order was completed.
00:21:21.160
Now, let's delve into the concept of event sourcing. Who knows what it is? Great! The general idea of event sourcing is that rather than storing data in databases, applications simply capture events. For instance, when a user is created or an order is placed, an event is stored. This event log is key to how our applications will run. Applications can then consume these events as needed.
00:22:29.740
In essence, various applications will react to these events. While working with Rails, you might opt for traditional data storage; alternatively, in systems keen on leveraging events, using libraries like Kafka to handle event sourcing can be illuminating. By calculating all events for a specific user, the system retrieves the necessary states allowing refined interaction with your databases.
00:23:12.280
For example, in a Hanami project, a web application might send events to an event log without needing additional applications. This can include persistent storage such as SQL or NoSQL databases, giving you full control over how you handle business logic while ensuring integrity. There are numerous pros and cons to this strategy, and while it's not a silver bullet for every case, it presents exciting opportunities.
00:24:38.740
As for tools, it’s good to check out libraries to manage event sourcing effectively, such as Relevant Store or Hanami Event, though they are still proofs of concept awaiting more thorough implementations.
00:25:15.320
Ultimately, it’s not merely about Hanami and Rails; our approach could involve using technologies like Dry combined with ROM. The important part is to isolate your business logic effectively.
00:25:51.600
In conclusion, maintainability is crucial in large and complex systems. I've referenced many ideas you can explore via the provided links, which include practical examples with Hanami. I welcome you to send me anything you’d like to discuss further, and I’ll make sure to provide those links in my replies.
00:27:31.940
Let’s go drink coffee! Thank you!
00:28:21.350
I see a question; nice! You’re my hero.
00:28:25.990
I want to ask about the relationship between models and repositories. I'm using Rails and want to make a comparison between Rails and Hanami. In Rails, there's ActiveRecord, but Hanami uses repositories and models. Can you explain the advantages and disadvantages of using repositories in this context?
00:29:29.250
In my opinion, Rails models contain a lot of logic, including validations, callbacks, and the actual data persistence functions. It may be beneficial to separate this logic into different areas since maintaining long Rails models can be cumbersome. Rails models often contain both class and instance methods, which can quickly become cluttered with responsibilities.
00:30:07.720
The advantages of using repositories are that logic is separated, making it easier to maintain and test. You can mock dependencies easily and test functionalities without heavy reliance on broader classes.
00:30:29.910
However, the downside is that it introduces an additional level of abstraction. You must carefully find a balance in your directory structure and documentation for clarity and ease of understanding among developers.
00:30:55.440
Thank you! You're welcome.
