Gao

meanwhile in the Night City

just knew i can make GPT silent. i told GPT “don’t ask a follow-up question every time”. after several rounds of discussion, i caught it asking again and said something, then it **actually** stopped replying

@arvin17x @yuwuxing 感谢你一开始推荐🙏

说实话，我们一开始推荐 logto 完全是因为你们 Guamian 主动找我并积极推荐，我才想着推你们一把。但当我们的用户遇到问题希望找你们帮忙时，你却说没有资源去别的项目里答疑。这就很难不让人带上有色眼镜。 如果按你的说法我们遇到的 issue 是用户匹配问题的话，那么你们当初就不应该宣传 logto 也适用于中小型项目，那我也就不会考虑集成。而我们现在遇到了问题又说不是你们产品的问题，是我们的用户群体不匹配，这就让人很难评了

分享很棒 👏 有不少选型我们用的也一样。同样分享下我们在做 SaaS 产品 LobeChat Cloud 上用的技术平台选型吧： Serverless 部署：Vercel Server 部署：Railway、Zeabur 数据库： Postgres Neon 用户管理： Clerk 文件/对象存储：Cloudflare R2 数据统计： Google Analysis / Plausible 邮件支持： Zoho SEO： GSC / SimilarWeb 支付： Stripe 这一套下来会有一些费用开支（几十刀/月），但能大大降低运维成本，体验非常棒~ 😆

@arvin17x @yuwuxing 嗯嗯，有报错就是产品做得不好🙅

@unusedsector @yuwuxing v1.19.0 -> v1.20.0，详见： github.com/lobehub/lobe-c…

@arvin17x @yuwuxing 你说得对👍

@unusedsector @yuwuxing > 如果用户反馈的都是真理，那是不是用户因为无法部署 logto 而骂你们的时候，lobe 就应该接下来这个锅？ 用户反馈的不是真理，但是口碑和声誉。所以我接下了在一开始推荐了 logto 的锅，并换掉了推荐的 auth 方案。使用 auth 方案的用户，大家都会用脚投票的。

@arvin17x @yuwuxing 你说得对👍

我并不觉得我的回答不专业。 1. 不支持 http 协议这个的确是 logto 不支持也不计划支持，那么针对想要用一个 auth 解决方案来处理所有业务场景的开发者用户来说就是一个产品能力缺陷。而且这个缺陷很隐蔽的地方在于，本地开发时的 localhost 虽然也是http 但其实等价于 https 。只有当去客户那部署的时候才会发现 http 用不了报错，这个时候就是开发者的 MMP 时刻； 2. 使用 Docker 镜像的确存在 Breaking Change 风险。我很清楚针对多容器的场景肯定有专业运维来处理，不需要我提醒。但是针对大部分只用一个 docker 容器跑的普通开发者，大部分人都不一定有专业运维背景。你不提供自动 db migration 的脚本，在他们的眼里看来就是挂了。 同样存在 db migration 的场景，国外其他一些服务像 litellm 的镜像就会为有 db 的版本自动带上迁移脚本，可以保证从任何一个版本升级上去都不需要用户感知db schema 的变化，不需要做额外的执行操作。 而这反映出来的问题就是 logto 预设的使用场景是有专业团队的更严肃的企业场景，那么面向个人开发者或小微团队来使用 logto 就一定会踩坑，而我告诉他需要注意的这两个事项哪里不专业了？

@arvin17x @yuwuxing 你说得对👍

@arvin17x @yuwuxing 所以还是用户场景匹配的问题。如果你对用户和技术都有这么深入的认识，我相信你也知道用户反馈问题并不一定是根本的问题，你对 @yuwuxing 的回答也会更专业。 如果用户反馈的都是真理，那是不是用户因为无法部署 logto 而骂你们的时候，lobe 就应该接下来这个锅？

> 1. 如果有多个实例，每个启动都需要执行自动化迁移脚本是吗？怎么感觉是一种 anti- pattern？ 看你放在哪个场景下看了，个人/中小微场景下几乎不会存在多实例，基本上单机每个都启一个容器跑就完事，不会存在你说的多实例的问题。 而会有多实例场景的一般都能有专业运维的人了，这种去跑 cli 还是自动执行都行。他们也不会随意变更。 > 2. docker 镜像只是计算资源，是整个系统的一部分，“升级”我理解是整体都需要升级，而不是只有镜像升级。 还是视角/场景不一样。如果你侧重的企业市场那可能的确如此。但我们的用户大多是一把梭到底

@arvin17x @yuwuxing 你推荐什么方案是你的自由，我们对场景的支持也是我们的选择。说实话你的用户提的这些 issue 我们都是第一次见，看起来更多是个用户匹配的问题而不是产品问题？如果因为被用户骂就带上有色眼镜，well

> 即便是 ip 也是可以使用 https 的，Logto 也有很多通过 proxy 实现 https 的案例。 ip 场景下使用 https 模式对于一些企业内网/个人 HomeLab 场景几乎不可行。LobeChat db 版上线一开始我们在官网文档上推 logto ，被提 issue 最多的就是内网(IP) 场景下， logto 怎么配都配不对，连带着我们被骂部署困难。 > OIDC 协议明确规定 issuer 需要用 https scheme，在我看来不应该归因于 Logto 你们对 OIDC 有坚持，不想支持 http 这个产品决策我尊重，所以我们在个人使用和 IP 场景下已经改推荐别的方案了，到现在也没啥部署问题的反馈。反而是没下掉的 logto 部署指南仍然会有用户提部署不了的 issue。 我们的自部署用户大部分都是 HomeLab 爱好者/科技发烧友 或者中小型企业，大部分并不关心 OIDC 是个啥东西，只要能完成登录注册就好，反倒是让他们在 IP 模式下弄出来 HTTPS 会把他们折腾死。

@arvin17x @yuwuxing 所谓手动触发 literally 也就是一个命令的事儿，并且启动报错里也明确指引了升级方法。 考虑到生产环境的复杂性，我们选择在不干预用户部署方式的前提下尽量提供便利，而不是为了某些特定的使用方式而破坏整体合理性。说实话，我确实没见过严肃的生产环境会直接升级所有计算和存储组件的，想想都危险

@unusedsector @yuwuxing 你说的这个 cli 并不是自动变更，仍然还是需要人来手动触发变更。 我理解的自动化应该是指用户的 docker 镜像升级时每次启动自动化完成 db schema 的 migration。这样才能确保不出现一升级就挂的情况。 否则用户一升级 docker 镜像版本，然后容器就报错退出，这在用户眼里就是 Breaking Change

@yuwuxing @arvin17x Management API 我们从第一个正式版开始也都保持了向前兼容

@yuwuxing @arvin17x Logto db schema 的变更都是向前兼容的哈，我们也提供 CLI 来帮助自动变更（我们自己也用） docs.logto.io/docs/reference…

@arvin17x @yuwuxing 如果你的用户不在意 OIDC / OAuth 之类的标准只是想快速集成一个可用的 auth provider，Logto 不一定是合适的选择。安全对于 Logto 十分重要。

@arvin17x @yuwuxing 即便是 ip 也是可以使用 https 的，Logto 也有很多通过 proxy 实现 https 的案例。另外，OIDC 协议明确规定 issuer 需要用 https scheme，在我看来不应该归因于 Logto。

@arvin17x @yuwuxing Logto db schema 时不时会改，但都是向前兼容的，我们也有升级指导文档。你说的具体是哪个版本？

@yuwuxing 抛掉这两个因素之外，logto 比较可取的地方就是 UI 和管理能接近 clerk ，在一众开源方案中算是体验还不错的。

the HN mod today likes CSS

failed

No coding challenge day 1

we love javascript