Ruby on Rails agreement. Part 4

Appreciate integrated systems

Ruby on Rails can be used for different purposes, but its strong point is monolithic integrated systems. Such systems are aimed at solving the entire problem together. Everything goes through Rails, from generating JavaScript to instantly refresh pages, and ending with database migration from one version to another when the project is already in use.

As mentioned earlier, in this formulation, the task is very broad, but it is quite within the power of one person. Rails is specifically designed so that one versatile specialist or small group can create a complete system. Otherwise, the experts are hammered into their highly specialized niches, and in order to implement a serious project, of these specialists you have to assemble a whole team.
')
It is the emphasis on empowering an individual developer that pushes us towards integrated systems. The integrated system allows you to remove unnecessary abstractions, reduce duplication between layers (for example, use the same templates on the server and on the client), and most importantly - to the last to prevent the transition to a distributed architecture.

The main complexity of distributed systems is associated with the emergence of new boundaries that make it difficult to transfer data between elements. Calling the method of another object in one object is much easier than calling a procedure from another microservice remotely in another microservice. In distributed systems, a number of complications unexpectedly appear, for example, scheduling dependency updates, unavailability of services and delays.

Alas, sometimes without distributed architecture is necessary. If your web application needs an API-interface to which users will access via HTTP, then nothing can be done - you will have to solve almost all the problems mentioned. It remains to be glad that working with incoming requests is much easier than outgoing ones, because if your interface does not work for a while, then the problem will be with you, the user of this interface. At least in this case, the inconvenience that you as a developer will have to endure is not so great.

It is bad when the system is split up prematurely into services or, even worse, into microservices. There is an opinion that when developing a “Modern Internet Application”, it will inevitably have to build the same system many times: once on the server side, once on the client side in the form of JavaScript MVC, once for each mobile platform, and so on . But this requirement is not conditioned by anything, so it’s completely unnecessary to do so!

You can easily use the same system elements for different tasks and access methods. Create a single set of controllers and views for desktop browsers and native mobile apps. Concentrate as many functions as possible in a monolithic integrated system.

At the same time, neither speed nor usability, nor other characteristics, for the sake of optimizing which developers rush to design a distributed application, practically do not suffer.

All our efforts are aimed at getting all the benefits of a perfectly tailored distributed application in a simple, convenient and understandable unified integrated system.

Progress above stability

When systems have been around for more than a decade, such as Rails, their natural tendency is ossification. There are a million reasons why each change can be a problem for someone else, for someone who depends on the past behavior of the system. And these reasons, in particular cases, are completely valid for individuals.

But, if we listen too closely to the voices of conservatism, we will never see the other side of the coin. We must sometimes take courage and change the conditions for how things should evolve and grow. This development will preserve Rails: both its survival and prosperity for a decade (s?) In the future.

This is all easy to understand in theory, but difficult to accept in practice. Especially when your application breaks down due to backward compatibility changes in the major version of Rails. It is at such moments that we must not forget that progress is beyond stability in order to get a charge of energy for debugging a bad code, finding out the problem, and finally moving further in the project life cycle.

This is not some permissiveness to cause someone unnecessary or excessive pain. The big transition from Rails from version 2.x to version 3 still stirs the wounds of those involved in this transition. This was hard. A serious commotion that many left on version 2.x for a long time, and some of them were already not to return from there. But, in the grand scheme of things, it was still worth it.

These are tough decisions that we must continue to make. Will Rails make the changes we make today better in the next five years? Will Rails become better at adapting a stack of new tasks, such as message queues or WebSockets, in the coming years? If so, let's roll up our sleeves and do some work.

This job is not just something that should happen exclusively in Rails, but also in the larger community of the Ruby language itself. Rails should be at the forefront of development, helping to promote Ruby, forcing its components to use later versions faster.

So far we have done this very well. From the moment I started, we went through Ruby versions 1.6, 1.8, 1.9, 2.0, 2.1, 2.2 and now at 2.3. A lot of major changes happened along the way, but Rails was directly present and involved in them to have Ruby under the hood and help everyone get through the development process faster. This partly privilege, and partly the Rails commitment, is the basis for promoting Ruby.

This is also true for supporting workflow tools. Bundler was once a controversial idea, but at the insistence of Rails that this will be the cornerstone of a shared future, today it’s a self-evident de facto tool. This also applies to tools and technologies such as the asset pipeline (file pipeline) and Spring, the pre-loader Rails application. All three tools went through the rooting stage, or continued to experience the pain of growth, but the evidence of their value in the long run helped us overcome it.

Progress, ultimately, is mainly related to people and their willingness to push for change. That is why in groups such as Rails Core or Rails Committers, do not sit idle. Both groups are designed for those who are actively working to achieve progress for the framework. For some, their contribution to such progress can be measured in just a few years, and we will be forever grateful for their work, while for others it can last for decades.

Accordingly, it is very important for this that we continue to welcome and encourage new members of the community. We need fresh blood and fresh ideas to make better progress.

Build a big tent

Holding such a large number of controversial ideas, Rails can quickly become an island of ideological hermits, if we always show full respect for all principles at once.

That is why we do not do that!

We need differences. We need differences. We need a variety of thoughts and people. It is in this crucible of ideas that we will get the very best to share it with everyone. Many people do their bit anyway, whether they are writing code or debating.

So, although this document describes a lot in an idealistic way, everyday reality is much thinner (and more interesting). Rails is capable of supporting such a large community in one tent precisely because there are very few “tests for the only correct approach” in its culture, if there are any.

As RSpec, DSL has continued to be tested, I have often expressed serious dissatisfaction, and this perfectly illustrates what has been said above. I can rant to the blue in the face, since I do not consider the Rspec to be a serious undertaking, and in spite of this, it flourished and flourishes as a technology. And it is much more important than the choice of any one, "the only true" technology!

The same can be said about Rails mode as an HTTP API. While I am personally committed to and focusing on an integrated system that includes views (views), Rails undoubtedly has a lot to offer developers who want to split their application into client and server parts (backend and frontend). We have to accept this, because such decisions can be developed in Rails as secondary, and I am sure that this is possible.

However, “having a big tent” does not mean trying to please everyone. It simply means that you greet all the people at the party and allow them to “bring their own drinks”. We should not lose any of our supporters or our values, inviting others to join us, and we can well learn to mix new contributions ("drinks") that came with those that already exist.

It is not simple. This requires that the community and the work in it be friendly and welcoming. Especially if your goal is not only to attract people similar to the already existing members of the community. Lowering the community entry threshold is a job that we should always take seriously.

You cannot know when a new developer, who has just begun to correct the spelling error in the documentation, will finish the implementation of the next big feature in Rails. And will he do it at all. But you have a chance to find out if you will smile, and if you will thank you for some small contribution, which allows the motivation to stay with each of us.

Thanks so much for translating railsfun

• Part 1
• Part 2
• Part 3
• Part 4