Search code examples
dockerrepositorymicroservicesweb-application-design

Web UI code and microservices in the same monorepo?


We are a startup and are beginning the process of porting over our entire web app to a decoupled concept where an Angular web UI talks to a collection of microservices. It's your standard modern approach. What is not standard about our strategy is that our CTO has strongly suggested (basically insisted) that we include the code for the Angular front-end in the same monorepo along with all of the microservices that are written in PHP/Lumen. The supposed advantage being that changes to common protocols (like JSON structure, etc) will be easier to deal with if everything is in the same repo. While I'm totally onboard for keeping all the microservices in the same monorepo I am really hesitant about throwing the Angular code in there as well mostly because I can't seem to find any best practices or precedent for doing this. I have searched and searched and no one seems to have an experience with this kind of setup that they are willing to share. Is there a recommended approach for this specific sort of setup?


Solution

  • If you look into "12 factor app with micro-services" you would get details about best practices.

    If you have your code in a single repo, with CI/CD tools a single checkin any where will deploy all services for backend system and UI on frontend at the same time, this may be ok at first but it will increase deployment times as you add more services, you may have to write some custom code to detect changes specific to UI/Services if you want to avoid this behavior, but you get the advantage of code sharing.

    You can code share even with multiple repositories if you keep your JSON structure in a common repository and share it on both client and server side.

    This all gets hard to manage and deploy once you add more types of clients for example, iOS/Android and as each team wants to own their own deploy and release cycles.

    At the same time you can start with single repository for simplicity, once you start seeing any of these issues, you can move them out into individual repositories.