最近与一个团队讨论了我们的警报堆栈。我去得有点晚，他们几乎已经完成了自己的内部构建。通话结束时，我们在讨论如果他们早知道我们的警报堆栈，可以节省多少时间。他们可能仍然会考虑用我们来替代。 我会继续说：构建警报并不是一件简单的事情。用户订阅、主题和频道管理、用于应用内收件箱的分页 API、未读徽章和已读状态、行动号召和分析。从 Firebase 打包的推送通知（是的，我们打包推送通知）。 而这与交付无关。想要快速接触到大量用户？这需要一些复杂的交付和排队基础设施。我们为 @jup_mobile 提供警报，这是加密领域中最快的移动应用（@weremeow，我说得对吗）。我们为他们处理了数亿个请求，包括他们所有的 Firebase 推送通知，毫无延迟。我们可以处理你的用户基础。 想要添加电子邮件、短信、Telegram 支持？每一个都是新的渠道集成和用户偏好的配置 API。 这仅仅是警报的基础设施。你仍然没有任何*真正好的*警报，而这些警报本身也需要时间来构建。如果你搞砸了，你会失去大量用户，他们会取消订阅并关闭你应用的推送通知，而现在你失去了最宝贵的参与工具之一。 以上所有内容都是 100% 的模板代码，这并不是让你的公司伟大的原因。如果你使用我们的警报堆栈，你将在极短的时间内完成基础设施，然后可以将所有注意力集中在发送*优秀*的警报上：从你的后端以一行代码发送个性化、及时的警报，甚至让你的增长和营销团队使用我们的仪表板发送产品更新和公司公告。 最后的点睛之笔：我们的警报堆栈是从零开始为加密构建的，你将以一种新颖的方式获得覆盖，通过我们的通用收件箱 📥，今天在 @jup_mobile 作为 Radar 运行。像 @jito_sol 和 @sanctumso 的团队正在将通用收件箱作为与 Twitter、电子邮件等其他渠道的新通信渠道。 换句话说：我们的通用收件箱更像是 SMTP，而不仅仅是 web2 警报 SaaS。使用我们的堆栈，你是在与用户的*钱包*进行沟通，它会随他们走到哪里。 说真的。选择生活。只需使用我们的警报堆栈。我们的文档经过了巨大的改版，阅读起来非常简单（感谢 @bjoerndotsol），如果你需要帮助设置，请私信我。 📥☀️