不要自己创建推送通知

乍一看，为你的移动应用程序或网站运行自己的推送通知服务器似乎很简单，但大多数开发人员发现自己陷入了麻烦的深渊。

想象一下这样的场景：你是一家移动应用初创公司的扑翼工程师。有一天，你的产品经理来找你，要求你建立一个系统，当他们关注的商品打折时，向用户发送通知。

“没问题”，你说，已经开始在Github上搜索一个开源库来帮助你做到这一点。令人高兴的是，您可以看到有两个流行的开源项目可以同时向iOS和Android发送通知。

像大多数开发人员一样，您在Javascript方面比Go更有经验。因此，您选择了流行的“微笑-SA/节点-推送服务器”项目。

兴奋地克隆项目并准备将其部署到Heroku，您恰好忽略了该项目自2015年以来就没有更新过。(与截图中的“3月21日”标签相反。这正是最后一期的报道时间。)。

一切正常，…。一段时间。然后，2020年11月来临，一切都崩溃了。遗憾的是，你没有看到苹果宣布他们将弃用旧的推送API的新闻。即使您看到了新闻，您也没有意识到“node-ush server”项目不支持该协议。啊哦。

你很快就会急于解决问题。每过一小时，你的应用程序就会收到用户的差评。你切换到下一个最受欢迎的项目“appleboy/gorush”。这个项目要复杂得多，需要运行Docker容器、Redis数据库，并学习如何设置和保持Go服务运行。谢天谢地，你让它工作了。

GoRush是一个受欢迎的项目，有超过690个提交。不幸的是，95%的承诺只由一个未支付的捐赠者完成。

在贡献者放弃该项目之前的几个月内，一切都很正常。你希望其他人能站起来接手。可悲的是，几乎没有人愿意承担一个复杂的开放源码项目的无偿开发的责任，每个月都会报告几十个问题。[这个例子还没有发生，但它完全在可能的范围内]。

通知API倾向于每年有意义地更改一次，时钟开始滴答作响地显示另一次“节点推送服务器”式的故障，就像您以前遇到的那样。

您曾短暂地考虑过自己学习围棋并承担维护工作，但很快就放弃了。您是移动开发人员，不是系统工程师。

您开始寻找替代解决方案，发现了Firebase云消息传递。它不是开源的，但它是免费的。它同时支持iOS和Android，而且它属于谷歌所有。“为什么我一开始就不用这个？！”您惊呼道，已经创建了一个帐户。由于有清晰的视频、示例项目和说明，整个过程非常顺利。

有一天，你的产品经理跑到你的办公桌前。“它又坏了！”她喊道。您意识到您的一些最重要的通知没有到达您的用户。最后追查原因，您发现Firebase没有正确地向用户组或Firebase称之为“主题”的用户组发送通知。

在通过Firebase支持表单发送了近12个错误报告后，他们终于在5天后承认了这个问题。松了一口气后，你拿了一杯咖啡，希望火基地团队几分钟内就能把它修好。可悲的是，在推出解决方案之前，这几分钟变成了12天。

在这17天的时间里，你的应用收到了数百条1星的评论。幸运的是，问题现在已经解决，您希望将来有更好的体验。

几个月后，你又遇到了问题。一些iOS用户没有收到通知。你认为这是Firebase iOS移动SDK的问题，然后你在Github上报告了这个问题。与您一起努力的还有其他几十名开发人员，他们正在为同样的问题而苦苦挣扎。该问题大约需要35天FireBase才能解决。与此同时，你已经失去了向大量iOS用户发送消息的能力。

“这应该很简单，”你想，想知道你哪里错了。

这太疯狂了。通知应该很简单。几乎每个应用程序都会发送它们，但是几乎每个人都会遇到相同的问题。

当我们以前是一家手机游戏工作室时，我们自己也遇到了很多这样的问题，于是我们创建了OneSignal。我们需要的不仅仅是“只需要工作”，还需要支持基本功能，比如细分、分析、A/B测试，以及与第三方系统的集成。然而，之前的一切都远远达不到最基本的要求。

我们看到许多开发人员犯了错误，试图运行他们自己的通知基础设施，结果却发现它很快就会在负载下崩溃，或者落后于技术变化。我们也有数以千计的开发人员从其他供应商(如Firebase)转向OneSignal，他们遇到了长期的服务问题或无法获得支持。我们终于简化了所有开发人员发送有效通知的过程。