In the current build, client is packaged as a Jar library and served from the server project.
That means a simple java -jar server.jar is enough to run the application in production.
But, this has some drawbacks, the first being some misunderstand on development workflow, because is better to use client tools like ng serve to develop, which use its on port.
Is more straightforward if the client was treated as a self served application.
The two could be linked using a proxy, that way all /api requests are redirected to the server IP address.
This also means we can scale the two applications, and have complete separate teams working. Also means a more micro-services oriented architecture.
Drawback is a more complex deployment operation.
Using docker with a orchestration tool like kubernetes, kontena or docker swarn, greatly improve on the complexity of deploying.
Doing this feature requires a different thinking and approach. Could this be a choice on project creation? If the cost of maintain two approachs is low, then yes.
In the current build, client is packaged as a Jar library and served from the server project.
That means a simple
java -jar server.jar
is enough to run the application in production.But, this has some drawbacks, the first being some misunderstand on development workflow, because is better to use client tools like
ng serve
to develop, which use its on port.Is more straightforward if the client was treated as a self served application.
The two could be linked using a proxy, that way all /api requests are redirected to the server IP address.
This also means we can scale the two applications, and have complete separate teams working. Also means a more micro-services oriented architecture.
Drawback is a more complex deployment operation.
Using docker with a orchestration tool like kubernetes, kontena or docker swarn, greatly improve on the complexity of deploying.