Show HN: 让用户掌控数据存储位置的 SaaS 应用开发框架

背景

在传统的 SaaS（软件即服务）应用开发中，数据架构通常遵循“后端为中心”的模式。开发者需要编写复杂的后端代码来管理数据库、处理业务逻辑，并严格管控用户数据的访问权限。这种模式虽然成熟，但也带来了显著的痛点：前端开发者需要处理繁琐的状态管理，后端需要维护庞大的授权逻辑，且数据所有权往往完全掌握在平台方手中，用户难以直接控制其数据的存储位置和访问方式。

LinkedRecords 提出了一种截然不同的范式。作为一个 NoSQL 数据库解决方案，它允许单页应用（SPA）直接连接数据库，无需编写后端代码。其核心理念是将数据的所有权和访问控制权交还给用户，通过内置的 API 级授权机制，简化了传统 SQL 世界中复杂的权限管理问题，旨在为开发者提供一种更简单、灵活且解耦的数据存储方案。

核心内容

1. 直接连接与无后端架构

LinkedRecords 的核心卖点在于其“无后端”（Backendless）特性。开发者可以将 LinkedRecords 直接集成到单页应用中，用户数据通过 API 直接写入数据库。这种架构消除了传统中间层的需求，使得应用构建更加轻量化。

2. 性能基准测试

LinkedRecords 提供了详细的性能基准数据，模拟了真实的文档管理场景。测试配置如下：

• 操作定义：createDocument 操作创建一个包含 8 个属性（7 个键值对属性 + 1 个长文本属性）的文档蓝图，涵盖文档内容、协作者/读者组、评论、引用和配置。fetchDocuments 列出用户的所有文档，fetchDocument 检索单个文档及其所有关联属性。
• 多租户模拟：测试环境包含三个用户角色：
  • 用户 1：持续创建文档（当前测试配置为 5,000 次迭代）。
  • 用户 2（被测用户）：每当用户 1 创建 10 个文档时，用户 2 创建 1 个文档，上限为 300 个文档。达到上限后停止创建。
  • 用户 3：偶尔创建文档（每 1,000 次迭代创建一次）。
• 指标：X 轴表示数据库中所有用户拥有的文档总数，Y 轴表示响应时间（毫秒）。

3. 数据所有权与授权模型

LinkedRecords 将数据库视为一个“桶”，任何注册用户都可以插入数据。只要数据未与其他用户或组共享，只有数据插入者能访问其写入的内容。

与传统 SQL 数据库不同，LinkedRecords 的授权逻辑发生了根本性转变：

• 传统模式：在后台定义适用于所有记录的通用授权规则。
• LinkedRecords 模式：授权内置于 API 中。数据插入者在插入记录时，直接指定谁可以读取该记录。这种“数据所有者定义权限”的模型简化了后端逻辑，避免了复杂的 RBAC（基于角色的访问控制）配置，尽管它要求开发者在思维模式上做出调整。

4. 设计理念：简单、灵活、解耦

• 简单性：API 端点和方法极少，仅由几个基础构建块组成。
• 灵活性：少量端点可组合以支持多种用例，内置的授权模型支持实现不同的授权场景（如 RBAC 等）。
• 解耦：LinkedRecords 与使用它作为数据存储的单页应用完全解耦。

5. 技术实现与配置

• 前端 SDK 集成：开发者需在 React 等前端应用中初始化 LinkedRecords SDK。示例代码展示了如何通过 OIDC（OpenID Connect）配置客户端 ID 和重定向 URI，并处理身份验证流程。

  import LinkedRecords from './src/browser_sdk';
  const oidcConfig = {
    client_id: 'your-client-id',
    redirect_uri: window.location.origin + '/callback',
  };
  const lr = new LinkedRecords(new URL('https://your-backend.com'), oidcConfig);
  

• 部署模式与安全：
  • 机密客户端模式（Confidential Client Mode）：会话令牌存储在 HttpOnly Cookie 中，这是从安全角度推荐的模式。但前提是 LinkedRecords 服务器与前端必须共享同一域名。
  • 公共客户端模式（Public Client Mode）：如果前端和后端不在同一域名下，Cookie 将成为第三方 Cookie，导致机密模式不可用。此时，单页应用必须在浏览器中存储访问令牌，并需配置相应环境变量。
• 存储后端：支持 PostgreSQL 作为主要数据库。若配置了 S3，则用于存储 blob 属性值；否则，blob 数据将存储在 PostgreSQL 中。建议配置 S3 以优化大文件存储。

关键要点

• 无后端开发：单页应用可直接连接 LinkedRecords NoSQL 数据库，无需编写传统后端代码。
• 数据所有权转移：数据插入者直接定义访问权限，而非由平台统一管控，实现了用户对其数据的完全控制。
• 简化的授权模型：通过 API 内置授权，避免了复杂的后端权限逻辑，支持灵活的访问控制策略。
• 性能可验证：提供了针对多租户环境下的详细性能基准测试，涵盖文档创建、检索及混合负载场景。
• 灵活的部署架构：支持同域（HttpOnly Cookie 安全模式）和跨域（Token 存储模式）两种部署方式，适应不同前端架构需求。
• 存储优化：默认使用 PostgreSQL，可选集成 S3 以高效处理二进制大对象（Blob）数据。
• 开发者体验：API 设计追求极简，提供类似 SQL 但更易读的查询体验，并支持实时数据更新。

意义与影响

LinkedRecords 的出现反映了 Web 开发领域对“去中心化”和“用户主权”日益增长的关注。对于开发者而言，它极大地降低了构建 SaaS 应用的门槛，特别是对于独立开发者或小团队，无需维护复杂的后端基础设施即可构建具备完整数据管理功能的应用。

从行业影响来看，LinkedRecords 挑战了传统的“后端即权威”的数据架构模式。通过将授权逻辑下沉至数据层面，它不仅简化了开发流程，还为用户提供了更透明的数据控制权。这种模式特别适用于需要高度数据隐私、协作性强或数据所有权敏感的应用场景。

然而，这种模式也带来了新的考量：前端直接暴露数据库连接可能增加安全风险，尽管 LinkedRecords 通过 OIDC 和内置授权机制进行了缓解，但开发者仍需谨慎处理跨域配置和令牌存储。此外，将授权逻辑分散到每条记录中，可能在大规模复杂权限场景下增加数据管理的复杂性。总体而言，LinkedRecords 为 Web 应用架构提供了一种值得探索的替代方案，特别是在追求快速迭代和数据用户掌控权的场景中。