Unified Architecture – Uncomplicated Method to Build Full- Stack Applications

Image by William Iven from Pixabay

Well- built applications are hard to find because they are hard to be made in the first place. A lot of different steps are involved in the design process and even if you do follow all of the processes, different types of drawbacks will appear anyway.

Compromise is the keyword we need to follow when it comes to designing an application. Besides that we need to stick to the six fundamental layers: data access, backend model, API server, API client, frontend model, and user interface.

By following the six layers one can achieve greatness but there are a lot of drawbacks as previously mentioned. Somewhere, the elements inside the module won’t be in order while somewhere the lack of simplicity will be visible.

Why is this a big problem? Well, the answer is very simple. Developers generally build every one of the applications differently and treat every one of it as a different sphere. This is why even after the implementation of the layers; a lot of difficulties are coming out on the surface.

First, each is built differently and cannot communicate easily between one another. Second, to connect them all you will need a code, and remember, after doing this, the domain model will duplicate everywhere on the stack. Thanks to it, the development of agility will be wretched and hurt.

Let’s look at the bright side for a moment because there is a way out of this mess after all. It is true that all of the layers must be physically separated however there is no need for them to be separated in a logical manner.

When it comes to object-oriented programming, when inheritance is involved, there are classes that can be spotted in two ways. The first one is the physical way and the second is the logical way.
Use your imagination for a moment. There is class 2 that comes from class 1. Then, 1 and 2 can be spotted as two physical classes. When you put logic into this, you will see that logically they are not divided, and that class 1 can be perceived as a logical class that merges properties of class 1 with its own properties.

This is an important example because it represents the core of our solution. If we apply everything discussed above to the layer of the application, then the frontend will inherit from the backend. In this way, they become one logical layer. Additionally, this removes all the communication and sharing issues. It is important to mention that the whole backend won’t be fully exposed. It will expose only some of its methods and attributes.

I won’t argue that sometimes inheritance is unable to bend. This happens when it is misused but even so, it is not bad at all. When it comes to this issue, it is inevitable because we have a problem and there is not a single existing language that will allow us to inherit classes around environments that are with multiple executions.

First things first. Let’s look at how all of the different layers can suit in a unified architecture.

Data Access – According to a lot of developers, for most of the applications or their database this problem can be easily solved. The database can be withdrawn with ORM. But, when it comes to applications that are more serious, optimization of the database schemas and requests is required. There is no need to make a mess of the backend model so we apply an additional layer. A data access layer is built later in the process, if there is a need for it of course, and we add it on top of the backend model without additional changes to the already existing code.

Backend Model – The backend model is forming the domain model, it is bringing business logic, and it is dealing with the authorization mechanisms. It is okay if you implement all in one layer. Of course, there are exceptions. It is possible to separately handle some concerns if there is a need for it. For example, if we want to divide the business logic from the authorization we can simply place them into different layers that later will inherit from each other.

API Layers – The web API, which is used to connect the frontend and the backend, makes a lot of complications. There are both sides that have to be implemented. This equals two extra layers, API client in the frontend and API server in the backend, which brings us duplication of the whole domain model. There is a solution to this complication as well. The unified architecture. If we decide to use it there won’t be a web API to build. Unfortunately, this solution does not come without additional problems. Building a web API is a clever idea when third- party developers are involved, take that in mind.

Frontend Model – There won’t be any additions to this model because the frontend model is going to be inherited from the backend model – the source.

User Interface – As I previously said, the frontend model is empty, so the User Interface can be implemented into it this no visible user interface is found. A separate layer will be required only when multiple platforms are involved.

Merging everything together was not an easy task. Here is the visual result of our work so far:

To successfully implement a unified architecture we need a cross-layer inheritance. You will have to build Liaison to achieve the perfect results. Liaison can be a framework for some and language extension to others. It has some similarities with COBRA, JAVA RMI or .NET CWF but its dissimilarities are bigger. Liaison is different because its backend is stateless; it is on the language- level, it has minimal API thus its design is straightforward, it does not bring boilerplate code, configuration files, artifacts or generated code. Deepr is used, a simple and at the same time powerful protocol that gives one of a kind features.

This is how Liason works:

First, the shared code between the backend and the frontend:

Second, you should build the backend in order to bring the business logic:

Third, it is time to build the frontend:

You can’t spot the increment ( ) method in the shared class or frontend class, right? You can also spot that it is visible only in the backend? This is happening because the frontend class is registered in a layer that inherits from the backend. This means that when a method is cut in the frontend class, and a method with the same name is present in the backend class in an automatic manner is invoked.

In fact, it is notable to mention that as long as a class is registered with the same name in the frontend and in the backend, every single instance present can be transported in an automatic matter.

Overriding a method across the frontend and the backend can also happen and the process is basically the same as in regular JavaScript. By using super, increment ( ) method can be overridden:

Building a user interface with React looks like this:

Lastly, visualization of the counter:

We all have to keep our minds open because the programming world is changing and change is always good. Unified architecture is a good switch and a full-stack application is possible.

It is important to mention that Liaison is still in progress and will be launched in early 2020.