I think the most immediate recommendation is to treat your Angular application as an entirely separate package from the Spring application. Interactions between these two applications should be done entirely over web protocols (HTTP/HTTPS and JSON or WS). I recommend using Docker to create isolated networks that both of your applications can use to communicate with each other. I personally start off making a sort of mock back-end with Rails or Node while I build my front-end application. Once the mock is not sufficient and real operations need to occur, I'll swap out the mock back-end container for a real web server container. If all is configured properly, then this change will go unnoticed to your Angular application. Further, if you're crafty with your configurations and networking, each of your services can be in a different technology. Ex. My employer owns a back-end series of services that range from Java to Go to Python.
To add to this, thinking of the front end and back end as two separate things will also help you see a lot of security and us implications that may otherwise be missed. Things like auth, error handling, and how data is sent and received are all significant aspects to consider. When creating your SPA, treat the API as if it is some random API you're using on the internet. Same for when your developing the API. Never trust the client, and always validate everything.
That said I actually have my API serve the SPA, and add the base href in dynamically. This way we can deploy it to any folder structure without worrying about re-transpiling.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the most immediate recommendation is to treat your Angular application as an entirely separate package from the Spring application. Interactions between these two applications should be done entirely over web protocols (HTTP/HTTPS and JSON or WS). I recommend using Docker to create isolated networks that both of your applications can use to communicate with each other. I personally start off making a sort of mock back-end with Rails or Node while I build my front-end application. Once the mock is not sufficient and real operations need to occur, I'll swap out the mock back-end container for a real web server container. If all is configured properly, then this change will go unnoticed to your Angular application. Further, if you're crafty with your configurations and networking, each of your services can be in a different technology. Ex. My employer owns a back-end series of services that range from Java to Go to Python.
To add to this, thinking of the front end and back end as two separate things will also help you see a lot of security and us implications that may otherwise be missed. Things like auth, error handling, and how data is sent and received are all significant aspects to consider. When creating your SPA, treat the API as if it is some random API you're using on the internet. Same for when your developing the API. Never trust the client, and always validate everything.
That said I actually have my API serve the SPA, and add the base href in dynamically. This way we can deploy it to any folder structure without worrying about re-transpiling.