In the past few days, I have been revamping several personal projects of mine. Some of them involve merging the frontend and backend into a monolithic application within node.js for unified management, while others involve replacing external databases with embedded ones. In a nutshell, what I have been doing is consolidating systems that were originally separated. In the current trend of microservices and frontend-backend separation, why do I choose to do this? Simply put, it is for the convenience of development and maintenance.
I used to emphasize the separation of front-end and back-end, as well as the SOA architecture, even in personal projects. This ensures the scalability of the overall project and prevents any small change from affecting the entire system. To achieve this, I divided the front-end and back-end, as well as the database, into separate components. Even for simple services, I split them into smaller independent services for deployment, and I divided the project into modules of the smallest granularity. I can't say that what I did was wrong. Doing so in a sufficiently complex system can indeed facilitate effective collaboration within a team and ensure the availability of services.
However, in reality, this approach has caused me a lot of unnecessary trouble for my personal projects. I have to monitor the status of multiple services simultaneously, which takes more time during deployment and development. While separation solves the problem of team division of labor, it actually increases the overall workload. And for individual developers like me, there is no division of labor issue to begin with.
I have a few small projects where I simply fetch data from external APIs, store it in my own database, and display it on the frontend. The combined workload of the frontend and backend is less than 1000 lines of code. However, I decided to separate them and deploy the database separately. In fact, it is unnecessary for this kind of application with low access pressure to use an external database if the database is only used as a cache, as data persistence is not a concern. Similarly, for personal projects where the frontend only displays CRUD operations on the backend data, there is no need for separation. Of course, if rendering the frontend directly on the backend causes other issues, separation should be considered. A monolithic application can also eliminate network latency in inter-service communication.
After compressing the entire system, I didn't have to worry about the scalability of the project, and instead felt relaxed. I can package the entire project into a Docker image with just one command, or deploy it directly on AppEngine, without having to worry about maintenance in the future. We can address future scalability when it is truly needed, without overdesigning the architecture in the early stages of development.