明白了，回头需要写个啥东西去 vercel 上玩玩，很有意思
解决首屏慢的终极方法应该是做桌面端…
为了数据完整性牺牲一点时间，这个可以理解。
不过有一点，好像使用了server db 就完全抛弃浏览器的缓存；
例如，我开启了客户端发起请求，历史上下文，每次都有重新再请求server 获得全量历史；
某些请求我感觉完全可以延后，因为它不会影响数据的完整性，例如话题的获取与生成这类。
数据库版，感觉浏览器缓存真的是没有一点用了，切换一下页面，就重新请求了一下对话列表。
是的，一直在等。现在用pwa过渡一下
我想吐槽一下现有的服务端请求方式，我发现客户端承受了太多不应该发送的请求。
例如，没有开启客户端请求模式时：
客户端视角：
- 用户发一个消息，server返回msgid：正常逻辑
- 客户端发送一个“…”的消息：为什么？
- 客户端请求lambda/message.getMessages：为什么要请求完整的历史上下文？
- 发送与大模型对话的请求“api/chat/openai”：为什么？
- 客户端接收消息
按照正常链路，客户端这里2.3.4 请求都是多余的，不必要的动作，服务端在用户发送1. 时就应该处理历史等各种配置数据，并与大模型开始交互了，完全没必要由客户端发起，这只会让整个过程变得非常慢。
1 Like
对，现阶段是这样。因为如果现在搞缓存，要做好的整个成本很高，也不一定能做准。而后面将 client 和 server 统一实现方案之后这个缓存方案又是废的。所以综合考虑下来目前就全走 server db 了，本地不做任何缓存。
所有事件都由客户端发起这个原因我已经在前面讲过了：
2 的目的是为了创建一条 Assistant 消息作为占位，此时并没有开始实际的 ai 请求；
1、2 是顺序的，但是 3 我记得不是阻塞的，相当于创建消息之后确保拉取到的是最新的结果。
4 是触发大模型对话的请求 api ，也由客户端发起，由于2 已经创建了消息，4做的事情就是updateMessageContent
你提到的正常链路是假设只有服务端 db 模式，没有客户端db 的模式，那是应该这样。
但是我们不一样，我们是先有的客户端 db，后面才有的服务端 db。
1 Like
看来还是历史包袱太重了，再重新规划耗费的精力太多。 
1 Like
我倒不觉得是历史包袱，反而是合理的技术演进路线。现在的客户端实现在未来改造 pglite 后将变成很大的优势，既能享受到 client db 的毫秒级响应，还能用上 server db 的云端同步，做到类似现在 Apple iCloud 的本地优先，同时也支持云端同步的丝滑体验。
届时 LobeChat 就是市面上唯一一个达到 Local First 终极目标的开源产品。
1 Like
史诗级加强。 跟 openwebui是一样快。我再多对比下
跟着大佬学思路