How to separate a part of the VueJs project in Laravel?
We wanted to separate a product from our monolith project. Although the transformation we made in Insider was similar to the micro front end, this structure was not exactly suitable for us. Although the basis was the same, the procedure we had to do was slightly different.
We are already using a design system. It helps us in the separation process. You can find the article about what it is below.
Since we have a Monolith FE project, more than 10 teams are developing this structure inside. This slows us down during development, code review, and deployment. In general, each product has a subfolder and the visuals are independent of each other. This made it easier for us to work with a proxy pass in Nginx from another repository than the micro frontend. Here is how to pass code to s3 on the Nginx side.
Although the first method that comes to mind was to offer the product through another domain, it was easier to proceed with the proxy pass as cookie management, login, and JWT processes would take time. In fact, the micro frontend structure works in this way, but with one difference. We do not need such a structure when multiple products are presented on the same screen for the micro front end, but we also know that we can easily provide this in the future. Also, you can find “what is the ideal?” below.
How do we handle the separation process?
First of all, the problem is backend and frontend are in the same repo. This means 30 different PR merges almost every day for us. There is no suitable situation for the separation process in this case, as there are ongoing changing codes. Here we first started by copying our Frontend code to a new repo, and created a standalone build process. However, new codes continued to be added during the tests.
We started by setting two dates for our product. All developments up to that date will continue and we will do our tests for the new repo and copy all our code after that date. Then our development will continue until the second date and we will create two PR from the same code for both repositories but we will not care about all other products. Because they will not be in the new structure.
The critical point here is that we have made sure that there is no problem by meticulously following the operation of all test cases and automation. For this, while subfolder-1 is the old structure, subfolder-2 is our new structure, although you can access it during testing, we did not use this link in any menu. Again, in a critical situation, we have directed the backend routes containing subfolder-2 to the subfolder-2-API section, otherwise, this subfolder will become unavailable to the backend service. When the second date came, we went live and only started dealing with our product’s code.
So what did we gain after all this?
Acceleration in the development process, acceleration in the review process, acceleration in the deployment process, decrease in cross-team dependency, development only locally with Frontend container, a healthy hot reload, page speed with loading routes only from the frontend, and independent deployment.
What did we lose?
2 times updates for common components (it can be only a version update), 2 times implementation of general bug solutions, and some consistency problems with other products.
Summary
By separating our product our review and deployment process has accelerated by 400% and we gain a custom deployment process. The next process is clean-up; We extracted the codes of our product from the old repo and everything except our product from the new repo.
What’s next, lots of refactoring😎
