How to wrap multiple Spring Boot applications in a single one

Question

I am working in a team, which is developing new web applications versions for our old solutions, but there are some innovative ideas as well. We are using Angular at the front end, Java at the back end, MongoDB for database and running it via Spring Boot.

At the current stage, we have two applications finished, and more in development. Now, we run them separated, they are different applications that are running in different ports with very specific purposes, with the only exception being the design as we tried a bit hard to keep some sort of usability pattern.

However, we are now looking more and more to the future and realizing that besides the goal of each application being very specific, they actually compose a bigger product that could wrap everything inside.

What we plan for now, might be very simple to describe, but I want to read more about it to make sure we are in the right path to integrate the applications. Basically, you can consider a menu fixed on top which will display all the available applications based on the logged user permissions. After that, once he/she selected one, the flow should be the same as it is inside the selected application when running separately (but the menu still).

Does anyone have any recommendation, or anything that might help us build this in a proper way? (as it will be easier to integrate things now than in the future)

Answer 1

I'm pretty sure that there can exist reasons for doing that, but depending on business needs, the solution may be quite different. Here are the two options, that you can consider:

1. Containerization of you apps. Put each app into a docker container, then use docker-compose to run both on the same server at the same time. You can use API gateway or proxy to expose both services via single entry point. The main benefit is that you'll be able to scale it to multiple servers, if necessary, and you don't need to touch the application code, preserving the modularity.

2. Plugin architecture. With some modifications to the configuration of Spring, you can treat the original apps as plugins, implementing some API. You put the plugin configs in some common classpath folder, e.g. /META-INF/plugins/pluginN.xml, so it will be discoverable by the host app. You write the host Spring Boot app, that will load the plugins via Spring DI by searching the configs in the classpath. The plugins will contribute the request mappings to host app WebMVC config, exposing their part of functionality. Pros: a) you still preserve modularity. b) smaller image size and memory/CPU usage on server. Con: requires careful thinking about Spring configuration and plugin architecture. Not scalable in "microservice architecture" sense (still can be deployed on multiple machines as a single app doing everything).

Answer 2

Well no. They don't compose a "bigger application" unless you want them to.

You're headed down the road of Microsoft Office. You're contemplating making a monolith. This is a business decision. One you will be judged for. It has nothing to do with better design.

What has to do with better design is the integration you mentioned. Trying very hard to present a uniform user experience is good. Having them work together is good. This is exactly what UNIX command line tools are. They work together. They have a uniform way to interact with them. They are not a monolith. They are a lot of little tools that work well together. They are integrated.

If you want to make a monolith fine. But don't claim it's the only way to make the applications work together. That is an independent choice.

If you simply want a way to signal how well integrated they are in your marketing, just give their icons a consistent theme.

Answer 3

Wrapping multiple Spring Boot applications does not seem to be the solution. If you want a single container, build the applications as war files and deploy them to a single container.

You may still be stuck with the issue of calling back to the container to access different layers. You may want to package certain modules as libraries and use them directly. You will already have developed a decoupled module, keep it that way by using its interface.