[Versión en castellano]

2021_07_15_devops03

One of the issues that concerns me the most not only is it how we do things, but why, and that is a more complicated question that it seems. You could do something because you were taught to do it in that manner, because it’s the way to do something in your industry or even because it’s trendy, to name but a few. Being all those answers valid, to a certain extent, they aren’t focusing on the real problem, we do something to help others to achieve their goals. Hereby, the answer should be what we do aims to solve a business problem.

The question and its answer are common to many industries, and software one is obviously one of them. As a matter of fact, we are used to talk about SOLID principles, about testing and many other issues, but mainly from a technical point of view. Have you ever wondered how addressing a proper software architecture help business achieve their goals? To give you an example I’m going to focus on two different business cases.

• Developing products intended for businesses (EE or customer): Being successful requires that your product could be adapted to different needs. Therefore, you need to ensure that your product could be customized and extended, supporting functionalities not previewed before and that only make sense for some clients, preventing generalization.
• Developing products targeted to End Users: In this case, your product will have to adapt to different needs quickly, supporting A/B marketing strategies and even try-and-discard ones. Hence, your product will have to support this functionality, this ability to be customized, to go in one direction and afterwards go in a different one or even backwards, not incurring in too much cost.

Moreover, you should take into account that when you develop software you are always developing products, even if you work for a consultancy firm or a software factory, your developments isn’t your product, but certainly it will be your client’s one.

Hereby, your software needs to be developed in a way that could fulfill these needs, and that means considering all the issues you should know about, and which are merged in SOLID acronym. Yet it includes many principles and ideas and all of them are utterly important, from the business point of view perhaps the more critical all those related to extensibility and dependency on abstractions.

As a matter of fact, those two features are intimately related, both for backend and frontend development, although your programming language, the used framework or the provided abstraction could be clearer or not.

Technical point of view

Moving on to the technical side, question isn’t if we use annotations, Spring Boot IoC, Angular IoC, whatsoever. But how these frameworks provided tools could help us to achieve our business goals. I mean, is it enough an @Autowire annotation to decide which implementation should we use? Do we need something more? How are we going to solve these problems within our software architecture?

Each problem requires, probably, its own answers, so I’m going to give you a glimpse of the different approaches that should be considered.

Backend side

Depending only on standard annotations isn’t enough. Although autowiring mechanism seems magic, it just follows a set of rules, and using it properly to fulfill business goals requires considering:

• Isolating different implementations in different modules.
• Depend on abstraction, not implementation.
• Actual implementation dependency should be included in build script.
• If inheritance is involved, implementation discovery should be performed using properties files, database or any other non-code-related mechanism
• Don’t forget about language provided extensibility tools, for example services extensions in Java Language.

Old frontend ways

Talking about old frontend ways, is talking about PHP pages, JSP pages or even ERB templates in which a modern JavaScript framework is not involved. Nevertheless, being "old" doesn’t mean that these extensibility problems shouldn’t be addressed. While some frameworks as RoR provided a remarkable extensibility engine, in other cases you should provide your own mechanisms. In any case, following issues should be considered:

• Your view should be properly isolated from your business logic.
• View should be componentized.
• View could be replaced using an extensibility mechanism, RoR has its own opinionated way, when using other frameworks, you should perform the same magic, for example deciding which JSP to load using a customized RequestDispatcher.
• View isn’t only a template but text. As you know, text shouldn’t be directly written on your view template but depend on an external set of message files. Obviously, these messages could be also customized on a client basis, perhaps you could even need to store these messages in a database so your customers could modify them in an easy way. If you are a Java guy, you should consider customized ResourceBundle and ResourceBundle resolution.
• Same problem happens with CSS resources, you should be worried about which set of CSS files you are going to use. In fact, it’s a problem about theming, and how these themes are going to be used in a proper way.

Modern frontend ways

Problems don’t disappear when using a new technology, in fact sometimes they get stronger. Developing a frontend with a modern framework as React or Angular involves resolving problems in a different way, somehow more related to backend mechanisms than to old typical frontend ones.

In the old ways deciding which view to load was the "global framework" responsibility, which could decide the best fitted page for the involved task. In this day and age, responsibility is upon the frontend, which should be the only responsible of providing proper extensibility approaches (this could be nuanced, but I’m not going to go deep inside).

Solutions involve:

• Proper separation of functionalities, so they could be plugged and plugged, and used independently.
• Isolate between common libraries and implementation.
• Use some framework provided mechanisms (React Contexts, Angular IoC) to decide which "component" to load in each case.
• Learn from old frontend ways, regarding matters such as messaging or CSS theming. Don’t reinvent the wheel.