我不确定我是否已经非常了解 node.js，但我真的很想实现它，因为我所理解的非常有趣。
我有一个使用第三方 API 的移动应用程序。用户通常会打开它以查看是否有任何新内容。我突然想到，只要我尊重第三方 API 的轮询限制（和其他限制），我就可以模拟一个基于推送的系统，并允许在有新内容时通知用户。
基本上以某种时间间隔从 Node.js 服务器实现所有 API 轮询，并使移动应用程序指向我的 Node.js 服务器而不是端点 API。
我认为这会很好，原因有很多：
- 减轻手机的数据使用负担（因为我可以在手机和服务器上缓存内容）。对于拥有按字节付费数据计划的用户来说，这是一个巨大的胜利
- 允许存储/访问所有数据的中心位置
- 让我在服务器端做一些优化（如果两个用户碰巧订阅了同一个提要，我可以在一个请求中得到它。
我认为这可能很糟糕，原因有很多：
- 如果我的服务器出现故障，那么我所有的应用程序都会死掉。通过充当我的 Node.js 实现之间的中间人，很可能会引入更多的故障点。
- 当第三方发布对 API 的添加时，它需要我在两个地方实现更改，而不是一个。
我的问题是：总的来说，这是一种好的做法吗？如果不是，为什么？