[优化建议]: 建议将 Caddy 和 blog server 的逻辑拆开

[wujun4code]

功能概述 | Describe the feature

整个项目用 docker compose 启动毫无任何问题，但是出于以下几个因素，我想阐述一下，为什么我建议将 http 代理服务器和本身的业务逻辑拆分。

1. 不管是 nginx 还是 caddy 亦或者是 traefik，它们哥几个都职责单一。

vanBlog 是个博客，一个简洁的 cms 网站，放在它之前的这一层反向代理没有必要存在于业务逻辑代码内，nestjs 框架也没有推荐内置内嵌一个 http server 的组件在项目内。

3. 关于 https 证书，certbot 或者是 LetsEncrypt 本身就已经很好用了

Caddy 是一个不错的项目，它的自动化 https 证书的确很赞，在 docker compose 本地启动的时候，配置参数本身就不多的时候，Caddy 相关的配置就占用了一大半，对于很多新手启动整个项目的时候，还得去研究一下这个 caddy 到底要不要配置一下，有一丢丢强迫症的人，可能项目还没启动，就去搜索 caddy 相关的参数了，容易带跑偏。

3. 如果一定要内置 caddy，放在 docker compose 里面

我觉得应该是将它跟 mongo 一样，当作一个推荐的组件，使用 vanBlog 的人可以有选择的要或者不要。

[Mereithhh]

感谢反馈

为什么要用 Caddy

VanBlog 内部是有很多微服务组件的，要想顺利运行，必须要有一层内部反代或者说 API 网关，这是刚需，不是可选项。只不过 VanBlog 把内置 Caddy 的存在暴露出来了，给了用户更多的可能。

Caddy 的存在也不是内嵌到 Nestjs 的，它在容器内的存在是独立的服务，只是后端会通过 Caddy 的 API 进行操作。后续 VanBlog 的一些高级功能，也会用到 Caddy 可以通过 API 在运行时灵活修改配置的能力。

关于编排的复杂性

我希望 VanBlog 是一站式的个人博客解决方案，能尽可能减少用户部署时的负担，目前已经有计划把编排文件中的配置项全部挪到后台初始化页面进行配置。

当配置项精简后，起一个 VanBlog 项目，你不需要修改除了端口映射之外的任何配置项，一切配置将在后台可配置并可热重载。甚至支持 SQLite 这类嵌入式数据库之后，只需要类似 docker run -d -p 80:80 mereith/van-blog 一行命令就可以了，这是我设想的最终效果。

关于证书

您提到的内置 Caddy 会让新手苦恼于配置，但我认为 Certbot 或 letsEncrypt 本身可能更会让新手苦恼。内置 Caddy 你不需要改默认编排的任何选项，只需要改一个 EMAIL，当你需要 HTTPS 的时候，全自动签名甚至不用写域名。但如果你用 Certbot 之类的，你需要了解证书的基本知识，需要敲命令行，学习成本会更高。

实际上到现在为止，很多人问过我各种各样的问题，但没有一个人是关于内置 Caddy 的，相反有不少人和我说全自动 HTTPS 真方便。 毕竟有些人买一台服务器，只是为了部署 VanBlog，他们不懂什么是证书，什么是 LetsEncrypt，如果取消内置的全自动 HTTPS，会显著增加他们的学习成本。

参考

内置 Caddy 具体起了什么作用，您可以参考一下 https://github.com/Mereithhh/van-blog/blob/master/CaddyfileTemplate

实际上操作 Caddy 的代码在： https://github.com/Mereithhh/van-blog/blob/master/packages/server/src/provider/caddy/caddy.provider.ts （只是包了 Caddy 的 API，没有任何与其他业务代码耦合）

[wujun4code]

嗯，您这么解释之后，那我完全理解了这个设计，我觉得也没问题。

不过我已经着手准备用 vanBlog 开始搭建自己的博客，不过我的选择还是在 外面再套一层 nginx 的代理，因为我这个 nginx 不只是要处理 vanBlog 还要处理其他的小型服务，小站点就不纠结多层代理的性能问题了。

[Mereithhh]

您可以把 VanBlog 内部的看成一个整体，不用纠结它里面有啥。。。 对于一个容器内部作为 API 网关的反代来说，性能损失我认为可以忽略不计的。

实际上层层反代在云原生时代太正常了，最起码部署到集群就有一层 ingress controller，如果用了什么中间件之类的，反代层数会更多，但很少见因为这个影响性能的，您不用太纠结。如果 VanBlog 哪天性能瓶颈了，那肯定是其他方面导致的。

[chenrizhi]

作者可以考虑把各个服务单独打包，给高阶用户灵活部署使用。

[Mereithhh]

作者可以考虑把各个服务单独打包，给高阶用户灵活部署使用。

实际上现在每个组件（在 packages 目录中)，都有自己的独立 Dockerfile ，单独打包是没问题的。

有空我会加一个单独打包的 Workflow 和单独打包的 k8s / docker-compose 编排放到项目文档中，但可能不会像正常部署那样有详尽的说明，毕竟是高级用户了嘛 :)