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)
How to wrap multiple Spring Boot applications in a single one
web applications;web services
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: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.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).