Run Time Modular Spring Boot
Building a modular system can shorten development times, improve code management, prolong system life span, and provide a more efficient deployment of different packaging matching a different set of users’ requirements.
In compile-time modularity, the developer is required to declare which modules an application will use. When the required modules change or when a module is updated, the whole system must be re-built. Most developers think of compile-time modularity when modularity comes to mind.
On the other hand, a run time modular system can dynamically be deployed by simply including different modules in the deployment or adding new modules to an already running system.
Run-time modularity is based on plugins or Micro-services.
Most modular systems including Spring’s own multi-modules one are of a compile-time type. That is, dependencies must be declared before a system is compiled, and a new combination of services requires a new build process preceded by dependencies declarations. This is normally followed by a full set of testing cycles for all of the system components.
A Maven-based project also uses the compile-time paradigm where all dependencies must be known before compilation.
Micro-Services are clearly of the run-time type, however, topology decisions on Micro-Service are tough, read https://dzone.com/articles/7-things-to-consider-while-moving-to-a-microservic
When using an in-process plugins system, de-coupling takes a different level even when using the same database. A service provider (in a plugin) can be extended and changed without the intervention of the development team responsible for that service and without affecting other services dependent on it.
A run-time plugins system should support in its plugins system:
What is Modular Development?
modular development is a software design pattern separating software components into modules each handling specific concern.
Why Build Modular Applications?
Modular applications are more easily maintained, have shorter development cycles, and can be packaged according to requirements.
Different Types of Modularity
Modular systems can be either for compile-time or for run time.
Run-time modular systems are much more flexible as modules can be deployed without changing other modules and with re-compilation.
Also, run time modular system, when built correctly, requires no prior knowledge or declaration of possible modules. Thus, the set of services a system provides can be altered by distributing a different set of modules. Existing systems can be extended endlessly using endless deployment combinations.
Dependencies in run time modular systems
Understanding the dependency paradigm in a modular system is crucial.
When a system can be extended without being aware of the possible services it can accommodate, a different level of productivity and flexibility can be achieved.
A Container (Spring Application) X is hosting 3 plugins A, B, C. X has no declarations of Either of A, B, and C.
Plugin C is injected into plugin D. That is, plugin D is aware of C existence and services but not vice versa.
At run time, the Container collects the plugins A, B, C, and D and injects C into D. Services and entities defined in the four plugins become available to front-end and other clients using this backend application.
When additional services are required, new plugin E can be added to the plugins repository of the system adding the required services by introducing new ones or by extending the existing ones.
Modular Development with FlexiCore
FlexiCore is a run-time modular system framework.
FlexiCore implements all of the required features for a truly extensible and flexible modular system.
FlexiCore encourages and supports building solutions as sets of interconnected plug-ins, each developed using Spring Boot APIs, services, and paradigms. Each plug-in may depend on other plug-ins. All the components of a system are defined as plug-ins. Plug-ins have no limitations to what they define or provide, including the interfaces to front-end devices (APIs), the domain model (Database structure), and the business services.
The actual Spring boot application is FlexiCore itself, and it remains identical for any application domain without a change, pretty much like Spring itself (new versions are regularly provided). Besides providing many additional services on top of what Spring provides, FlexiCore manages the plugins and the inter-dependencies among them. This is carried out without any declaration of plugins to be used.
Special plugin support includes updating plugins remotely. This is implemented through the use of a Wizzdi provided plugin.
With FlexiCore plug-ins support, multiple versions of the same plug-in can co-reside.
Plug-ins can declare the required version of an injected plug-in using a different version from what other plug-ins may use, front-end clients and other systems using the system API can also declare a specific version they need to use.
Deploying new or updated plugins remotely is provided.
Different users of the same back-end can access different versions of the same plugin.
Because of the no-limitations nature of the FlexiCore plugins system, a huge repository of existing plug-ins is available, free to use, and extend. This capability alone, is a true game-changer,
Concrete examples of Modularity through plugins
Ready to get started?