返回首页
最新
嘿，HN！
我正在开发一个新应用，希望它能够像 Linear 一样快速且响应灵敏，具备实时查询、同步和写操作的能力。
我对此并不是专家，所以欢迎大家来给我普及一下。我已经研究了一些选项，比如 Convex、ElectricSQL、Zero、Liveblocks 等等。
我觉得这些选项在某些方面总是有所欠缺，最好的总结就是它们的模块化。
我希望在一个同步引擎中实现以下几点：
- 能够使用我的数据库（Postgres，AWS RDS）
- 能够在我的后端形成并执行查询（假设我在 Next.js（Vercel）中有前端，并通过 API 路由连接到我的 FastAPI 服务器（AWS ECS），在这里我有所有的身份验证/权限中间件等）
- 有一种简单且熟悉的方式来向同步引擎声明模式（比如重用 SQLalchemy 或 Drizzle 的模式）
- 一个简单的 SDK 来形成使用 SQL 的查询
此外，我想知道这样的系统如何与连接池、分片、复制等功能协同工作。
是否有类似的解决方案存在？或者有哪些主要挑战阻碍了这类解决方案的出现？
嗨，HN，我正在开发一个短视频应用（平均视频时长40秒，预计每天播放量在10,000到50,000之间，且在增长，其中20%的流量来自美国以外，80%来自美国，主要是移动端）。我正在考虑以下两个选项：
1. **Cloudflare Stream + Backblaze (B2)**：
优点：产品简单，按观看分钟数计费（可能比GCP在视频流媒体方面更便宜），内置转码功能。
担忧：不确定他们的自适应比特率（ABR）质量是否能与GCP的质量相匹配，后者在之前的使用中表现非常好。
2. **GCP (GCS + Transcoder API + Media CDN)**：
优点：我之前使用过这个配置，稳定性很好，存储成本低，网络费用也低，流媒体质量出色。而且控制台相对容易操作（尤其是与AWS相比）。我离开GCP是因为与视频流媒体无关的问题（视频智能API的费用异常高），但考虑仅为视频存储和流媒体回归GCP。
缺点：配置转码API时遇到了一些问题，并且担心随着用户增加可能会有隐藏的费用。
如果你使用过Cloudflare Stream或GCP的视频流媒体服务，我很想听听你的看法：
- 短视频的实际播放质量，尤其是1080p/720p的表现和比特率变化。
- 在Cloudflare Stream或GCP视频流媒体服务中，是否存在价格上的陷阱。
- 你遇到的可靠性/操作问题。
我目前倾向于选择Cloudflare Streaming，因为看起来更便宜/更划算，但对视频流的可靠性和质量有所担忧。因此，回归GCP进行视频流媒体服务也许并不是个坏选择。
期待你的想法，谢谢！
多年来，我安静地专注于我的工作，但现在我感到有必要指出一个日益明显的问题。
1. 正确的模型 ≠ 被采纳的模型
历史事实：在前端生态系统中，成功的并不是那些创造出最准确抽象的人，而是那些以最小摩擦提供“工作感觉”的人。
结果：正确的思维模型 → 低采纳率，而不正确但易用的模型 → 爆炸性增长。
这并非偶然。
2. 为什么基于意图/确定性模型没有成功？
有几个明显的原因。
认知负担：
意图 + 有限状态机 + 时间线需要：
“我知道我在做什么”，“我在设计生命周期”，“我在有意识地生成状态。”
但对于今天的前端开发者来说，这不是一个特性，而是一个障碍。因为生态系统奖励的是：快速演示、快速工作、快速简历。
对于这样的人：
有限状态机 = 恐惧，确定性 = 不必要，明确的生命周期 = “过度工程”。
用户界面的容错性非常高：
在后端：错误的抽象 → 系统崩溃，金钱损失，数据损坏。
在用户界面：加载指示器转动的时间稍长，状态出现故障，用户刷新页面。
换句话说：前端错误可以被容忍很长时间。这使得糟糕的抽象得以存活。
React的副作用：“隐藏、保存”文化：
React做了这一点：隐藏了生命周期，隐藏了并发，隐藏了协调。
结果：形成了一种“即使你不理解它也能工作”的文化。
这种文化：促进了仪式性的记忆，而不是工程思维。
写一个钩子，如果它能工作，那就好。但为什么能工作，怎么能工作？没有人会去问。
“氛围编码者”的爆炸不是原因，而是结果
因为这种情况并不是从ChatGPT、Gemini、Claude或Copilot开始的。这些只是加速了已有的衰退。基础早已奠定。
已经有一群人不知道抽象，不知道状态是什么，不知道并发是什么，但记住了框架。
人工智能只是做了这一点：它使“我不需要思考”的感觉变得正式化。
4. 不是框架，而是基础设施层
最大的错误是：“让我们构建一个新的用户界面框架。”这注定会失败，确实失败了。
-> “https://dayssincelastjsframework.com/”
然而，如果创建一个定位为运行时层、意图引擎、状态协调器、提交解析器的结构，它就会成为一个在React、Vue和Svelte等巨头之上的隐形层。
采纳方式是这样的：“想用就用”或“如果不想用就根本看不见”。
5. 最重要的教训（或许是所有教训）
我清楚地写下这句话：“前端世界现在并没有产生工程，而是在产生流水线式的行为。”
这就是为什么正确的抽象不会立即获胜，但这是不可避免的。
因为：用户界面变得越来越有状态，人工智能交互在增加，并发是不可避免的。
在这一点上：“加载指示器 + 钩子”模型将崩溃，人们将不得不再次问“为什么？”
而且是的：“在这种混乱中呼吁标准是毫无意义的。”
但当从正确的层面、正确的问题和正确的痛点出发时，这个模型不可避免地会创造价值。
这不是关于炒作，而是关于耐心。
---
经过这些话，我意识到有抱怨，但解决方案在哪里？
我打开了一个GitHub仓库，并添加了一个“AI支持”的RFC提案。欢迎任何想要参与的人。
谢谢。
https://github.com/laphilosophia/temporal-intent-resolution
您今天需要解决什么IT问题？
我之所以构建这个工具，是因为我厌倦了猜测我的RAG系统为何会失败。它将用户查询与文档映射到二维空间中，以寻找“红区”（高用户意图、低文档支持）。这是一个开源项目，使用FastAPI和React构建。希望能得到关于聚类逻辑的反馈。