这两天改造了几个自己个人项目。有的是把前后端给合并到 node.js 里面形成一个单体应用，统一管理；也有的是把本来外部的数据库改成应用内嵌的数据库。大的来说，我做的事情就是把本来分离的系统给合并起来。在微服务和前后端分离流行的当下，为什么要这么做？简单地说就是为了方便开发与维护。
之前自己也一直强调前后端分离和SOA架构，即使是在个人项目里面，因为这样可以保证整体项目的可扩展性，不至于牵一发而动全身。为了做到这样，我把前后端给拆分，把数据库给拆分，简单的服务拆成各个小服务独立部署，简简单单的项目也都给划分成最小粒度的模块。我不能说我做的是不对的，在足够复杂的系统当中这么做确实能够让团队更加有效地合作，保证服务的可用性。
但是，事实上，对于我的个人项目来说，这么做反而给我带来了很多不必要的麻烦，我不得不同时监控多个服务的状态，无论是部署和开发的时候都需要花更多的时间。因为分离解决了团队分工难题，但是整体的工作量其实是上升的，而对于个人开发来说，本身就没有分工难题。
我有几个小项目，就是简简单单地通过外部接口，抓取数据，存到自己的数据库当中，然后在前端显示。前后端的工作量合起来不足1000行代码。但是我将它前后端分离，数据库单独部署。其实是没有必要的，对于这种没有什么访问压力的应用，如果数据库只是作为一个缓存，其实完全是没有必要使用外部数据库，毕竟并不需要在意数据的持久化。同样的，就个人项目，如果前端只是后端数据基础的CRUD展示，也没有必要进行分离，当然，如果后端直接渲染前端带来了其他麻烦，还是应该分离。一个单体应用还可以消除服务间通信的网络延迟。
将整个系统进行“压缩”之后，我没有因为为项目未来的扩展性而感到伤脑筋，反而感到一身轻松。我可以一条命令就将整个项目打包成 docker 镜像，或者直接就在 AppEngine 上线，不必再为后续的维护头疼。未来的扩展等到真正需要的时候再说，在开发的初期前要不要过度设计架构。