另外再提一点我自己的小看法：

目前 front 部分获取文章数据并渲染是应该是直接从 mongo 中拿的数据，是否更应该改为从 server 拿数据呢？使用 RPC 调用或 RESTful 接口调用的方式。

from blog.

关于BUG

😅front代码中mongo直连是昨天刚刚做的，忘了拆出来了，文档中server的nginx配置稍后更改

关于建议

• 我个人更倾向于独立成三个项目，待稳定后就拆
• 单独一个配置文件不大好，因为拆成三个项目后不好加载，可以弄成环境变量式的
• Docker和CI都会做的
• front由于是服务端渲染的，目前没找到比较好的解耦办法
  • 我之后会尝试是否可以在SSR服务端挂掉的情况下降级成纯nginx代理，顺带解耦一部分
  • 之所以只能解耦一部分，是因为前端用了个比较极端的优化手段，把所有前端路由全部都分块分出去了，具体可以参考这里

关于2L

个人觉得RPC调用对博客太重了，之前都是用RESTful形式来调的，昨天选择直连mongo后效果不错，去除HTTP开销足足降低了20毫秒的首屏请求，具体可以看下我刚总结的这篇文章

共同开发

肯定欢迎啦，你可以选一些TODO里没做的开做，或者提PR加TODO，我们讨论没问题就先合进来。

from blog.

Hello:
bug已经修掉了，mongo配置也已经暴露出来，同时允许使用RESTful接口进行数据获取，另外也调整了目录结构

from blog.

好的。我目前是把项目部署在 Docker 里面的，晚上有时间我来写一个 Dockerfile 吧。关于在 Docker 中部署我倾向于把 Mongo 和 Redis 外置，让使用者自己通过环境变量配置数据库的连接，而不是在一个容器里面同时跑 Mongo、Redis 和 Node。

不过整个结构对于 Docker 化来说还是有一定问题的，例如把所有静态文件打到容器里面会出现静态文件不好被加载的情况，而且暴露两个端口对于部署来说问题也是挺大的。

对于整体架构，我细想了下，分拆成三个项目以及合并为一个项目都有其优缺点。分成三个项目的好处自然是完整的前后端分离，方便分开部署，但无疑增加了部署的难度，这种分离方案对于一个博客系统来说是否有必要；合并成一个项目将前后台及服务部分分模块来管理可以大大降低部署的难度，对于前后端分离来说肯定就不够彻底了，但好在可以用一个端口同时支持 Server 和 SSR 甚至静态文件的代理输出（admin 部分只有静态文件，不需要额外的部署）。

权衡之下，我感觉合成一个项目并共用一个端口提供前后端的服务会更好一些。你觉得呢？

from blog.

环境变量这个确实需要加上。

至于整体架构的话，我还是比较倾向于把front和server分开部署，这样以后想写新主题的话，可以直接拿server的restful api开写一个新前端项目，方便写主题。有其他主题的情况下，合并前后端会导致默认前端被浪费。

提供restful api这一点是和静态博客最大的不同点，hexo等博客改主题说到底还是用的模板引擎，有了restful api后，用vue还是angular还是react就随便了，想怎么搞怎么搞。

因此，部署方面的话，我觉得分开部署front和server，分成两个Docker好一些。

这样的话，整个项目我想分成两个，一个是server+admin的仓库，一个front仓库，因为后台管理的主题需求很小，而博客前台front说到底只是一个前端主题，是和后端无关的，虽然它上了服务端渲染之后，有mongo直连这种歪门邪道

from blog.

Hello, 现在所有配置都支持环境变量了。如果你有其他想做的可以另开issue，或者直接PR也可

from blog.