Best Practice:Deploying Angular App and Spring REST Api

Question

I'm trying to deploy an angular application which communicates with a spring rest api.

The spring application is hosted on tomcat, and working as expected.

My angular app is a simple form, which also works in theory. Now I attempt to deploy both on my local system, and have the angular post data send to the tomcat server, where it will be handled by the spring app.

As this will be something I will develop continually over the next months, I am looking for advices on the best practices on deployment. Is it recommended to serve both from the tomcat container, or should there be a separation of concerns? I am also hoping to learn about scalability and architectures with this experiment, so using seperate vms, multiple servers, load balancing etc I am keen to understand and receive any helpful advice or pointers in the right direction. Thank you.

Answer 1

Separation of the user interface from the core business logic (backend) is a good choice if you expect your application to scale substantially (more services, frequent changes).

You took the first step right.

Here is what is my experience and what I can safely say as the "recommended" setup:

• Angular application and Spring based REST application are two disparate components of your web application. They are developed around different contexts of concerns. You will be able to maintain them well without breaking your whole application if you handle (develop, build and deploy) them separately.

• Separating out the user interface from the core business logic also helps you to use different technology stack for different purposes. What works better for building UI may not for backend or vice versa

• You mentioned that these components will continually evolve. Usually, they evolve separately. This is a best case for separate deployment pipelines (to build and deploy them separately).

• The Angular application could be hosted on node server while Spring based backend API runs on a Tomcat instance. This will also help you to load balance these components separately based on which component needs more attention.

• Due to this separation, the complete application does not go down during downtime. REST APIs could be down for maintenance or due to a fault but the application's UI may still be up and serving some requests which do not depend on the backend. This is far better than the application not being available at all.

• Techniques like feature toggles could be employed at the UI layer to disable some part of the functionality which depends on the backend or is half done. Though it is possible to do that in a single deployable application, it is much cleaner to understand and manage when the UI is separated out from the backend logic. The backend could have its own feature toggle framework (different than the one at the UI layer).

• In future, you could open up the REST APIs to the outer world (or other applications) and add more services which may not be required for your Angular application. Potentially, a dedicated team may work on the REST APIs component in the setup and it may make sense not to expose them to the Angular code.

• My favourite: treat the public facing Angular component of your application as a "client" for your Spring app (REST APIs). This makes the REST application "generic" and loosely coupled with the Angular component which has huge advantages in the long run.

Having said that, it is okay to start with a single deployment for both during the initial phases however you must be ready to extract out the components at the first chance.