最新

嗨，HN！ 我正在开发一款新应用，希望它能像 Linear 那样快速响应，实现实时查询、同步和写入操作。 我对这方面并不精通，欢迎大家指教。我研究过一些方案，比如 Convex、ElectricSQL、Zero、Liveblocks 等。 我觉得它们总是在某些方面有所欠缺，最能概括这一点的就是它们的模块化。 我理想中的同步引擎应该具备以下特点： * 能够使用我的数据库（Postgres，AWS RDS） * 能够在我的后端构建和执行查询（假设我的前端是 Next.js (Vercel)，有一个 API 路由指向我的 FastAPI 服务器 (AWS ECS)，我在那里处理所有身份验证/权限中间件等） * 有一种简单且熟悉的方式来声明同步引擎的模式（比如重用 SQLAlchemy 或 Drizzle 的模式） * 一个使用 SQL 的简单 SDK 来构建查询 此外，我还想知道这样的系统如何处理连接池、分片、复制等问题。 有类似的东西存在吗？或者是什么主要挑战阻碍了它的出现？

大家好，我正在开发一款短视频应用（平均视频长度40秒，预计每天播放量1万到5万次，并且还在增长，其中20%的流量来自美国以外地区，80%来自美国，主要在移动端）。我正在考虑以下两种方案： 1. Cloudflare Stream + Backblaze (B2): 优点：产品简单，按观看分钟数计费（可能比GCP的视频流服务便宜），内置转码功能。 担忧：不确定它们的自适应比特率（ABR）质量是否能达到GCP的水平，我之前使用GCP时效果非常好。 2. GCP (GCS + Transcoder API + MediaCDN): 优点：我之前用过这套方案，非常稳定，存储成本低，网络费用也低，而且流媒体质量极佳。控制台也相当容易操作（尤其是与AWS相比）。我离开GCP是因为与视频流无关的问题（Video Intelligence API非常昂贵），但现在正在考虑为了视频存储和流媒体服务而重新使用它。 缺点：配置转码API时遇到过一些问题，并且担心随着用户增加，可能会出现一些隐藏的费用。 所以，如果你使用过Cloudflare Stream或GCP的视频流服务，我很想听听你的看法： * 短视频的实际播放质量，特别是1080p/720p的播放效果，以及CloudStream的比特率阶梯。 * CloudStream或GCP视频流服务的定价方面是否存在任何隐藏费用。 * 你遇到过的可靠性/运营问题。 我目前倾向于Cloudflare Stream，因为它看起来更便宜/更划算，但我担心视频流的可靠性和质量。所以，也许重新使用GCP进行视频流服务也不是一件坏事。 期待您的想法，谢谢。

多年来，我一直默默专注于我的工作，但现在我感到有必要指出一个日益明显的问题。 1. 正确模型 ≠ 采用模型 历史事实：在前端生态系统中，胜出的不是那些创建最精确抽象的人，而是那些以最少摩擦提供“工作感觉”的人。 结果：正确的思维模型 → 采用率低，而错误但简单的模型 → 爆发式增长。 这并非巧合。 2. 为什么基于意图/确定性模型没有成功？ 原因显而易见。 认知负担： 意图 + 有限状态机 + 时间线需要： “我知道我在做什么”，“我正在设计生命周期”，“我正在有意识地产生状态。” 但对于当今的前端人群来说，这并非一个特性，而是一个障碍。因为生态系统奖励的是：快速演示、快速工作、快速简历加分 对于拥有这种背景的人来说： 有限状态机 = 恐惧，确定性 = 不必要，显式生命周期 = “过度工程” UI 的容错率非常高： 在后端：错误的抽象 → 系统崩溃，金钱损失，数据损坏。 在 UI 中：加载指示器多转了一会儿，状态出现故障，用户刷新。 换句话说：前端错误可以被容忍很长时间。这使得糟糕的抽象得以生存。 React 的副作用：“隐藏，保存”文化： React 做了这些：隐藏了生命周期，隐藏了并发，隐藏了协调。 结果：“即使你不理解它，它也能工作”的文化。 这种文化：培养了仪式性的死记硬背，而不是工程。 写一个 hook，如果它有效，那就好。但它为什么有效，它是如何工作的？没有人问。 “氛围编码者”的爆发不是原因，而是结果 因为这种情况并非始于 ChatGPT、Gemini、Cluade 或 Copilot。这些加速了现有的衰退。基础已经奠定。 已经有一群人不知道抽象是什么，不知道状态是什么，不知道并发是什么，但却记住了框架。 AI 只是做了这件事：它形式化了“我不需要思考”的感觉。 3. 不是框架，而是基础设施层 最大的错误是：“让我们构建一个新的 UI 框架。” 这会消亡，而且确实消亡了。 -> “https://dayssincelastjsframework.com/” 然而，如果创建了一个将自己定位为运行时层、意图引擎、状态协调器、提交解析器的结构，它就会成为 React、Vue 和 Svelte 等巨头之上的一个隐形层。 采用是这样的：“如果你想用就用”或者“如果你不想用就完全看不到它”。 4. 最重要的教训（也许是所有教训） 我清楚地写下这句话：“前端世界目前没有在产生工程，而是在产生类似传送带的行为。” 这就是为什么正确的抽象不会立即获胜，但它不可避免。 因为：UI 变得越来越有状态，AI 交互正在增加，并发是不可避免的。 在这一点上：“加载指示器 + hook”模型将会崩溃，人们将不得不再次问“为什么？”。 而且是的：“在这种混乱中呼吁标准是毫无意义的。” 但当从正确的层、正确的问题和正确的痛点入手时，这种模型不可避免地会创造价值。 这与炒作无关，而与耐心有关。 --- 说了这么多，我意识到有抱怨，但解决方案在哪里？ 我打开了一个 GitHub 仓库，并添加了一个“AI 支持的”RFC 提案。欢迎任何想加入的人参与。 谢谢。 https://github.com/laphilosophia/temporal-intent-resolution

您今天需要解决什么 IT 问题？

我构建这个工具是因为我厌倦了猜测我的 RAG 系统失败的原因。它将用户查询和文档投射到 2D 空间中，以找到“红区”（高用户意图，低文档支持）。开源，使用 FastAPI + React 构建。欢迎对聚类逻辑提出反馈意见。