By reading articles on the web I realized that it is better to have separated the back end application and the front end in their own repositories.
I'm working on big ASP.NET application, in which the client app lives inside it. Actually the server requires it in order to display some of its content (universal javascript). This makes it complicated to split these apps in separate repos. I'm thinking how complicated the development could be...
My question is do you have client/server separated? How you develop your applications together? How these apps are connected? Do you use any specific tool?
Bonus question: If you have multiple front end apps, how you apply changes between them? For example if B belongs to A, make a change to A and check the new updated version on B.
I found some solutions but I'm not sure if I'm in a good direction, using the best practice.
We have several applications with the requirement to separate the API from the UI to support Desktop, Mobile and web platforms. Generally you want to keep as much of your business logic in the API's and leave the UI's as "window dressing".
Here's an example project layout (simplified a bit):
ProjectA
Lately, my team has been using WebStorm for the UI stuff and Visual Studio for the backend stuff and the result has been fantastic. Separating the development environments helps keep you in a certain "head space" while you're working.
Just to provide a different viewpoint I'll defend the monorepo approach.
In the past I've worked on several projects that attempted to split up every aspect of the project into different code bases. This frequently led to a lot of internal dependencies that needed to be split out into their own repositories because they were used by multiple parts of the project.
This "many small repos" approach is not entirely dissimilar to microservice architecture. Microservices are great for handling scaling and complexity but they work best if you already have multiple small teams or intend to divide a project up into small teams. This social division in turn brings its own problems and there are again ways to address this by effectively making teams overlap in various way to counterbalance the division created by the different code bases.
One practical concern is that if you have multiple repos all using common internal dependencies you not only have different interests that need to be addressed when working on those dependencies, but you also need to keep everything in sync. Even without common dependencies it can be a hassle to clearly define which version of the server code works with which version of the client code and so on.
Of course in theory you're purely following RESTful HATEOAS conventions and provide a new API version on top of all the existing ones whenever an endpoint changes ever so slightly, but in practice some API consumers are more equal than others and especially during early development you may want to value the speed of iterations over academic purity.
A whole new level of pain begins when you start thinking of concerns like server-side rendering or have server-side concerns that are more about the frontend than about the backend. The division between server-side code and client-side code is rarely the same as the division between frontend (presentation) and backend (persistence). If you use React with server-side rendering you are literally running frontend code on the server.
Instead of strictly saying "client code should live separate from server code" I instead propose the following:
Think about what part of your code addresses concerns that are specific to each frontend (web, native, third-party consumers) and what part of your code addresses backend concerns (e.g. a public REST API or a database CRUD wrapper with auth). Keep each frontend and the backend separate. You may find that some frontends include both a client and a server, others may want to directly interface only with the common backend server, or if you don't need any client-side logic in your web interface there might even be a frontend that only consists of server code.
These divisions are far less arbitrary and far more maintainable than just splitting repos by where a line of code gets executed. And if you realise that the best choice for a project may be keeping it all in one repo, that's okay too.
I made several tiny apps before and I separated them in different repos. Now I considering putting them into one. Reason is I'm the only one maintaining this project I had to commit on both sides. Maintaining in one is always consistent.
Ryan Lynch
Software Engineer @ Squarespace
When I'm developing large applications I break the server up into independent micro-services, and I put the frontend code in its own repository or repositories. The tools you use to make sure everything is connected are integration tests, unit tests, and end to end tests. As far as the bonus question; if you have multiple frontend applications that share code, the frontend itself can be broken up into independent modules, which you can manage via a private npm repository. Keeping everything together and monolithic makes it difficult to reason about how the whole thing works together. By breaking things up you create cohesive chunks of functionality that can be worked on independently and reasoned about easily.