前端 API 密钥重构：Clerk SDK 开发者体验优化实践

重构前端API密钥：优化开发者体验的探索

与大多数开发工具类似，Clerk 的 SDK 也配置了两种密钥：一种用于后端，另一种用于前端。这种设计的核心要求是：

尽管前端密钥的安全性要求较低，但许多工具选择让前端密钥与后端密钥在格式和长度上保持一致。例如，Stripe 的密钥设计就是如此：

（不用担心，密钥已被重置。）

然而，作为一家专注于身份验证的公司，Clerk 对前端密钥有额外的要求，这使得简单地镜像后端密钥的设计会引发性能问题。

前端密钥的主要作用是作为与前端 API 交互的唯一标识符。以下是 Stripe SDK 使用可发布密钥的一个示例：

请注意，所有请求都直接发送到 stripe.com 域。即使开发者将 Stripe 的组件嵌入到自己的网站中，SDK 仍然会通过 Stripe 的域发起请求。

但对于 Clerk 来说，这种方式并不适用。由于 Clerk 负责运行API 请求通过客户的域名进行访问。这就要求开发者在 DNS 记录中设置 CNAME，以配置第一方环境。

在 Clerk 的早期设计中，前端密钥只是托管前端 API 的主机名。开发者在 React 应用中可以这样配置：

通过直接传递 API 主机名，我们避免了额外的 API 请求，从而提升了加载速度。然而，这种设计带来了一个意想不到的问题：开发者感到困惑。

主机名作为前端密钥的设计对开发者来说非常陌生。尽管我们在命名和设计上做了许多尝试，但仍无法消除这种困惑。这种问题在开发者的反馈中屡见不鲜，成为了集成过程中的一大障碍。

为了优化开发者体验，我们对前端 API 密钥进行了重新设计。新的密钥格式更接近 Stripe 的设计：

尽管外观上类似，但我们并未牺牲性能。新的可发布密钥中隐藏了一些微妙的设计细节：

此外，我们还调整了 React 的属性名称，使得新的密钥设计更加直观。

通过这次重构，我们在不牺牲性能的前提下，显著提升了开发者体验。新的前端 API 密钥设计更加符合开发者的预期，减少了初始设置过程中的困惑。如今，开发者可以更加轻松地完成集成工作。

原文链接: https://clerk.com/blog/refactoring-our-api-keys