简单方法的局限性

我们成功了——我们的实现已经通过了两项集成测试!

现在怎么办? 是要自我表扬然后将其投入生产环境吗?

别急。

我们一开始就说过——我们采用的方法是尽可能简单地启动并运行。

但是，这样就足够好了吗?

让我们仔细看看它的缺点!

1. 安全性: 我们的 POST /newsletters 端点不受保护——任何人都可以向其发起请求，并广播给我们的所有受众，而无需经过任何检查。
2. 您只有一次机会: 一旦您点击 POST /newsletters，您的内容就会发送到您的整个邮件列表。在批准发布之前，您没有机会在草稿模式下编辑或审阅它。
3. 性能: 我们一次发送一封电子邮件。 我们会等待当前邮件成功发送后再继续发送下一封。 如果您有 10 或 20 个订阅者，这不会造成太大问题，但很快就会变得明显：对于拥有大量受众的新闻通讯来说，延迟将会非常严重。
4. 容错: 如果我们发送一封电子邮件失败，我们会使用 ? 将错误冒泡，并向调用者返回 500 内部服务器错误。 剩余的电子邮件永远不会发送，我们也不会重试发送失败的邮件。
5. 重试安全性: 网络通信时，很多事情都可能出错。如果我们 API 的使用者在调用我们的服务时遇到超时或 500 内部服务器错误，该怎么办? 他们无法重试——这可能会让新闻稿再次发送给整个邮件列表。

第 2 点和第 3 点虽然烦人，但我们可以忍受一段时间。

第 4 点和第 5 点是相当严重的限制，对我们的用户有明显的影响。

第 1 点是没有商量余地的：我们必须在发布 API 之前保护好端点。