8

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)

| improve this question | |
2

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).

| improve this answer | |
  • Great answer, and thank you for understanding what I really asked. I have to say that this question was intended to find out a good approach to do what I described, but unfortunately, there is no time left for decision making anymore. However, I will accept it as it actually answers what I asked, and because it's a very good start to accomplish what I wanted and may be very helpful for any future reader in a similar situation to mine :) – Patrick Bard Oct 24 '16 at 13:11
1

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.

| improve this answer | |
  • I didn't mean to be claiming that this is the only way to make the applications to work. Well, they work very well a part from each other and they could still be used that way, however there is a bussiness decision here to intregrate the way we deliver them. – Patrick Bard Aug 24 '16 at 11:26
  • And yeah, when I said that they compose a "bigger application", that's why we wanted to. – Patrick Bard Aug 24 '16 at 11:28
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.