In the previous post we went through the use cases for using StormHub Engine, but this time we will deep dive in the Engine features. In this text we will go thought the most important ones where we will try to balance real life examples, but also provide certain technical insights how is the Engine designed “under the hood”.
One of the main concepts of the StormHub Engine is a possibility to have multiple applications built inside one solution. We call this multi-application feature.
Various application use cases can be connected and still have completely different purposes. When we are talking about user experience with modular approach, there are different possibilities. For example, applications can have completely separated look and feel, or they can relate to the same portal where a user can easily navigate between them.
The same applies to the data layer, where applications are using the same Engine components, but application relevant data can be stored in different databases. On the other hand, applications can exchange information and share the same data model.
With this approach, solution architects and designers are having a perfect foundation to deliver solution of any complexity with best possible user experience.
Nowadays, one of the most common requirements for web applications is a possibility to have multiple tenants running on the same solution. Based on that, this is one of the most important features of the Engine, which we pushed even further.
Not only that multiple tenants can run on the same solution, but there is a possibility that the same users can be assigned to one or more tenants with a different set of privileges. We will talk about that part in more details down the line.
Beside users, there is a possibility to design a business layer to also share data between tenants. Imagine the case where an application is built for end users, but also another application which can be consumed by business partners.
Nevertheless, a part of the multi-tenancy is also flexibility to design the applications to support businesses (B2B) or private persons (B2C) at the same time.
Security is one of the main parts of any digital solution and access control plays the key role. That’s why we put a special attention and effort to design a solution, which is fully secure, but also has all the flexibility to be dynamic and customizable as possible.
With all this in mind, we came up with the solution which we call “Dynamic 4-tier user access control”. As the name says, the whole solution is designed to have different roles and assigned privileges on four different levels.
The highest level contains main operations of the solution and actions which can be configured and assigned to different roles. Going lower we have tenant and application levels, which in some cases can be bellow each other, but it’s not mandatory. In each tenant, or in each application, there is possibility to setup different roles, with again different privileges. The lowest level is for application specific entities. For example, in the project management application, there are projects where it’s possible to configure different roles and actions assigned to each one.
It sounds complicated, but everything is intuitive and configurable over the user interface. The Engine is making sure that all the connections and rights are assigned without any manual intervention.
Now, it’s time to go a little bit more on the technical level. When we are talking about solution architecture, the Engine is designed to follow microservice and event driven approach. That means that it is built from many smaller parts, where each part is application itself. Each application, or service, is performing a specialized task, or better to say it’s responsible for certain specialized operation. For example, this can be running certain background task, or expose certain endpoints, which can receive some input and produce some output.
Having many services working on separated operations and fulfilling different business needs, is increasing solution robustness and stability. If one type of the services stop working, others will continue which makes less risk for users to experience the problem in the whole solution.
Beside running services, there is also an important aspect of communication between them, which also needs to be designed to be reliable and support different kind of business needs. Here we talk about event driven architecture where services are not talking directly. They are communicating by listening different events. In Engine those events are published on the message broker and then picked up by services which are subscribed to receive the same.
There are big benefits of using the event driven approach and one of the biggest is reliability where published messages are stacked until certain service picks them up. In case no service is available there are mechanisms in place which makes sure the messages are not lost, and they will eventually be processed. The good use case for this is logging mechanisms, where logs are stacked on the queue until they are processed. In case no processing service is available, they are not lost.
There are some drawbacks of using the event driven mechanism like speed. For that reason, in the Engine, we are not using only event driven architecture. There are several different communication methods and mechanism implemented to best fulfill requirements from different components.
One of the StormHub Engine parts is also billing components. That component is tightly connected with subscriptions and usage tracking. Most of the SaaS businesses today have a subscription-based model, where customers are paying for things they are using in the solution. That’s also possible with the Engine, where you define your billing items and subscriptions, connect them with multi-currency price lists and track them when users enable or disable each item.
As you can already imagine, there are plenty of possibilities and different use cases Engine supports. From monthly or yearly subscriptions to one time charging. Beside all of that, there are configurable and automated discounts, possibility to set up affiliate programs and much more.
In this article we went through the most important features of the Engine. The Engine is built to support a huge range of use cases and it’s designed to fulfill complex scenarios without any compromises on reliability, performance and security of the solutions. For any question or if you are looking for more information, please reach us at info@stormhub.cloud.