-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Front 部分的 mongo 配置未暴露出来以及一处文档错误 #7
Comments
另外再提一点我自己的小看法: 目前 front 部分获取文章数据并渲染是应该是直接从 mongo 中拿的数据,是否更应该改为从 server 拿数据呢?使用 RPC 调用或 RESTful 接口调用的方式。 |
关于BUG😅front代码中mongo直连是昨天刚刚做的,忘了拆出来了,文档中server的nginx配置稍后更改 关于建议
关于2L个人觉得RPC调用对博客太重了,之前都是用RESTful形式来调的,昨天选择直连mongo后效果不错,去除HTTP开销足足降低了20毫秒的首屏请求,具体可以看下我刚总结的这篇文章 共同开发肯定欢迎啦,你可以选一些TODO里没做的开做,或者提PR加TODO,我们讨论没问题就先合进来。 |
Hello: |
好的。我目前是把项目部署在 Docker 里面的,晚上有时间我来写一个 Dockerfile 吧。关于在 Docker 中部署我倾向于把 Mongo 和 Redis 外置,让使用者自己通过环境变量配置数据库的连接,而不是在一个容器里面同时跑 Mongo、Redis 和 Node。 不过整个结构对于 Docker 化来说还是有一定问题的,例如把所有静态文件打到容器里面会出现静态文件不好被加载的情况,而且暴露两个端口对于部署来说问题也是挺大的。 对于整体架构,我细想了下,分拆成三个项目以及合并为一个项目都有其优缺点。分成三个项目的好处自然是完整的前后端分离,方便分开部署,但无疑增加了部署的难度,这种分离方案对于一个博客系统来说是否有必要;合并成一个项目将前后台及服务部分分模块来管理可以大大降低部署的难度,对于前后端分离来说肯定就不够彻底了,但好在可以用一个端口同时支持 Server 和 SSR 甚至静态文件的代理输出(admin 部分只有静态文件,不需要额外的部署)。 权衡之下,我感觉合成一个项目并共用一个端口提供前后端的服务会更好一些。你觉得呢? |
环境变量这个确实需要加上。 至于整体架构的话,我还是比较倾向于把front和server分开部署,这样以后想写新主题的话,可以直接拿server的restful api开写一个新前端项目,方便写主题。有其他主题的情况下,合并前后端会导致默认前端被浪费。 提供restful api这一点是和静态博客最大的不同点,hexo等博客改主题说到底还是用的模板引擎,有了restful api后,用vue还是angular还是react就随便了,想怎么搞怎么搞。 因此,部署方面的话,我觉得分开部署front和server,分成两个Docker好一些。 这样的话,整个项目我想分成两个,一个是server+admin的仓库,一个front仓库,因为后台管理的主题需求很小,而博客前台front说到底只是一个前端主题,是和后端无关的,虽然它上了服务端渲染之后,有mongo直连这种歪门邪道 |
Hello, 现在所有配置都支持环境变量了。如果你有其他想做的可以另开issue,或者直接PR也可 |
你好,
最近一直打算自己用 Node 写一套这样的博客系统,今天看到你的博客感觉不错,并且开源,于是试了下。以下提出一些建议以及 BUG。
建议:
.config.yml
文件BUG:
front/server/mongo.js
中,这会导致无法启动 front有没有兴趣一起开发这套系统? 😀
The text was updated successfully, but these errors were encountered: