Mixing server and client code in monorepo

Question

To date, we have implemented a multi-repo approach in which each project, or for larger projects, each tier, has its own repo. Code is written in Typescript, Javascript, C#, PowerShell and T-SQL. We currently have 75-100 applications. Some are strictly server-side, some strictly client-side, most are mixed - a client application that calls a server endpoint which calls into a DB.

I've been researching monorerpos and can't find anything that discusses mixing server code (C#, Powershell, T-SQL) with client code (Typescript, Javascript) in the same monorepo. Is this a good idea? What are the benefits/drawbacks? In all my reading on monorepos in general, as well as specific toolchains (Microsoft Rush and Nrwl Nx primarily) I can't find any mention of this approach and I can't figure out whether it's because it's no big deal or because it's a stupid idea prone to fail.

Any information and/or links to resources where I can read up on this would be helpful.

Thanks,

TTE.

Answer 1

Yes it is possible, but the question is: why your company required separate repositories in the first place? Usually when a project reaches a stable version the GUI changes more often than the backend. If the employer want to keep track of the changes and the costs and you keep backend and GUI on the same project you will end up providing to your managers a mixed up history of the changes that is more difficult to follow. Then there is the issue with granting access to the developers. If you are going to do everything by yourself it would be no problem. But if the team grows and people get specialised on one of the two part is it still worth to grant them access to the entire code base?

So a single repository for a small project that is beginning just now or a small company with few developers would be all right. But then deciding if it's worth it or not depends both on technical factors like the deployment practices and non technical factors like the organisation in your company.

Answer 2

Should be fine and makes keeping them in sync easier. Before making a commit or merging a branch one can run the complete test suite including integration tests to validate minimum compatibility requirements.

If fact I'd do this by default, unless they were huge or some other reason like different teams or companies were developing them. Or perhaps one part is mature, and the other is rapidly developing. But, these should be uncommon cases.

(I'd still keep associated projects that aren't directly coupled separate however.)

Answer 3

The code repository is just a tool that has to do its jobs: tracking changes happening on a file system made from a number of people. It should be agnostic about the language(s) and the architecture of the application(s) hosted. In fact, you can also set up a repo to manage images or simple text files.

In my experience I saw companies adopt different approaches depending on the overall SDLC tools, the codebase size, the number of devs and the external dependencies that need to be managed.

Single repo pro

• Easier to implement and set up.
• Developer can "jump on'' the code easily.
• Refactoring will be easier for sure.
• Easier to find conflicts in case of dependencies update.

Single repo cons

• It exposes a single "point of failure". If something goes wrong, the whole code base is effected and all the developer can take an holiday.
• Synch and merge will require more time and resources. Slower SDLC.

Multi repo pro

• Suitable to set up access rules.
• Every operation to perform is more lean: run test, perform code metrics checks...
• Made possible to perform granular release.

Multi repo cons

• It could require more effort to keep align the dependencies.