And suddenly we realized that the single page applications are just too heavy for mobile phones and we needed to address this. And people were used to having fast websites, so suddenly when you had to wait minutes for something to load, it just didn't work. And this led to a birth of Jamstack, where we needed something that was fast and light in contrast to the large single page applications that took minutes or dozens of minutes and megabytes to load.
We needed to address the elephant that is trying to be squeezed to a straw. It was the birth of the first meta frameworks like Next, Nuxt, or Gatsby or popular today Remix, Quik, and Astro that bring something new to the table, where we finally had pages that were fast to load, where you would immediately see the results. Unfortunately, all of this came at the expense of developer experience. In order to have fast websites for users, we had to do heavy lifting on our own machines, so our build processes became super slow. And not only this led to frustrating developers, but when we consider that most of the CI and CD is now pushed to cloud, if our build processes were slow, that also meant that our monthly cloud builds were getting higher and higher.
It was time to address the second part of the slowness, so now websites were slow but we needed to work fast, but we needed to speed up our developer experience. This led to monorepos. In order to understand what monorepos exactly do, let's first consider our typical web application today. Our application usually consists of a front-end application build with your chosen framework, and then we have some back end which is not a monolit back end but has some micro-services architecture behind, and then you have some UI components. Now what happens occasionally is that one of the developers working on back-end slightly changes a method in one of the services by that changing a contract, and simply forgets to inform you the maintainer of front-end, and suddenly your website is broken, everyone is pointing fingers at you, and you have no idea what happened because you didn't touch that code.
There are some clunky attempts to solve this by constantly exporting contracts from the back-end, converting them to TypeScript and importing them in your front-end applications so that you always have up-to-date information, but this requires manual intervention, and when it comes to human factor, given enough time, it will eventually fail. And on top of that, there is a sync issue because if something changes in the back-end, you have to roll this out at the same time on front-end, and there is a lot of coordination and juggling involved. On top of that, your application might not be the only one. There might be two additional applications, a dedicated mobile and dedicated admin portal maybe built with completely different technology that is also shared among different applications.
Now, what you want to do is that whenever one of these changes, each part of the system that has been affected by it immediately is notified. Now, in a typical poly-repo approach, what happens is that, for example, if you change the utility, you would have to publish a new version, then you update the dependencies in a home page application and admin portal, and then test if this works. If it doesn't work, you have to go back again, make a fix in utility, again publish a new version. Of course, you can solve this with, for example, SIEM linking or some local repository, but it requires a lot of coordination, a lot of things that you need to maintain, and on top of that, this doesn't scale well.
Now, wouldn't it be nice if they could just simply talk to each other? So whenever something changes, the entire ecosystem already knows what happened. And this is what happens with collocation. Collocation means that all of these projects are sitting in the same repo. So whenever one of these changes, all the projects can immediately see that because they are sitting together, so there's no need to publish a new version, no need for any rolling or any other rituals. Now, having things collocated also helps us to identify certain functions that can, for example, be reused. So if you have some sophisticated admin function like this in your code, you can easily tell your colleagues, hey, I have this amazing function, maybe you want to use it in your project as well? And they can see it and they're, yeah, amazing, we need this for mobile phone as well. And you can easily extract this into a library and share it with everyone else in the repo. And when people think about monorepos, this is what they usually think about, that it's just about collocation. But it's not just about collocation.