Angular + Spring Application

Question

I use Spring for backend work and Angular for frontend and maintain each in separate repositories.

This was because I considered both the frontend and backend completely separate projects, IE a new frontend can be developed in an entirely different framework and it'd still work with the existing backend and vice versa; they are in no way tied down to each other.

I've been reconsidering this as I learned one can have their Angular site served through Spring, rather than using NGINX/Apache. This would allow deploying the two as a single application and reduce the need to run two web servers. (Tomcat/NGINX)

Is this normal and is it advisable to do? I partially feel it's better to keep them separated, for example by deploying them as a single unit the frontend is now a part of the backend, even if only visual changes are made, parts of the backend would have to go offline just to deploy those changes?

I can also see here that Spring have bunched up both projects in the same repository. Is this normal as this project structure appears to be somewhat messy compared to for example in a single repository just having a frontend/website and backend/api directory, or better yet, two separate repositories?

Edit
Didn't notice until I posted this, the link in this post is a Spring/Angular JS repo, while I use Spring/Angular CLI, just for clarity.

Edit
I've also discovered it's possible to serve the frontend with Spring, without the frontend being inside the application. (Allowing it to be replaced very easily.) Thanks to the spring.resources-static-locations configuration in application.yml which makes this a little more appealing now.

Edit
Looking further into it, it seems the choice is either:

1. Spring for API + NGINX for Frontend with Reverse Proxy to access API.
2. Spring for API, with external static resources hosted on a Google Cloud Storage Bucket so that the website can be updated without the backend having downtime. The site is served by Spring, but still completely separate from it.

Answer 1

In the application I'm working on we started by serving the angular files by a mvc controller. While that worked ok, we are in the process of putting the static files in cloud by putting the entire application behind an amazon cloudfront where we reverse proxy /api to on-prem and the rest from a s3 bucket.

In our case the amount of static files leaving our datacenter was 80G/day which was more than we expected. When we put that in AWS the price will be 7$/day which I consider extremely cheap.

Putting the application behind a CDN you also have the benefit of caching if any of your APIs have a cache header, they will be cached in the CDN and you save some on-prem bandwidth.

So I will recommend option 3:

Google cloud CDN and reverse proxy /api to on-prem and the static files served from a google cloud storage bucket

(I assume google cloud CDN have the same feature as amazon cloudfront which I'm more familar with. I use google in this answer. It might as well be AWS)

Answer 2

I've done some research and lots of deployments and came to a conclusion which I'll document below.

Context: My goal is to deploy a backend and frontend in a simple scalable way which will be easy to automate the end-to-end deployment, triggered by a GitLab tag, all the way to an updated website with no downtime.

The backend will not be referenced in any decision-making as I will just be running that on Kubernetes, that was a simple decision on it's own.

Now regarding frontend...

Spring (Rejected)

• Want frontend and backend to be deployed as completely separate units.
• They're in separate git repos, deployed in separate docker images. (Subjectively simpler to develop and review.)
• Easier versioning makes little sense for the backend to update what's it's serving if it hasn't versioned.

A list of options for web hosting on Google Cloud Platform:
https://cloud.google.com/solutions/web-serving-overview

Storage + Google CDN (Rejected)

• Doesn't offer end-to-end encryption.
• Configuring routes was a pain - especially as I'm developing an Angular site where 404s need to go to index.html.

Firebase (Rejected)

• Offered more I didn't want, than did want.
• When researching, most info was for web applications made with Firebase and its additional features such as DataStore, and Authentication. It seems more popular amongst users seeking serverless features while I intend to run a backend anyways.
• Minimal configuration, including SSL/TLS certificates. I'm using Cloudflare and so would like to use my Cloudflare certificates, not Let's Encrypt ones.
• Firebase is separated from other Google Cloud Platform tools, if I wanted to the frontend on / and backend on /api/ I simply wouldn't be able to, the loadbalancer doesn't include Firebase apps, having to release the backend on api.host.tld instead. While this isn't that bad, having the choice taken away from me is irritating.

Google Compute Engine - NGINX (Rejected)

• It seemed I wouldn't save any money, but would have much more flexibility and ability to scale, and ease of deployment by using Kubernetes instead, that's all.

Google App Engine (Not Considered)

• Skipped - no objective reason. Just doesn't look entirely appealing having "Google manage it for you", perhaps I will reconsider once I am more familiar with Google Cloud Platform and what that automagic management entails.

Google Kubernetes Engine - NGINX (Accepted)

• As I run the web-server myself, I can manually configure whatever I want including gzip compression, or enable CA verification to ensure people only visit via my domain, and not by the server IP directly.
• I'll be using Kubernetes already anyways, this just means 2 pods per node instead of one.
• Seems like the most flexible approach as it'll just be small configuration changes to change how to access amongst other settings.
• Frontend will scale with the backend. (Unsure how handy this is for a static site.)
• I'm using Cloudflare as a CDN anyways already.
• Seems easy to automate deployment. (Definitely not as easy as Firebase though.)