是否有用于缓冲API请求的分布式方法？
我仍在学习如何使用API，并想知道采取我所拥有的最明智的方法（在下图中的“ A”），并将其重构为我想要的东西（“ B”下图）。
主要思想是我当前的WebApp直接通过（他们的）API直接到达外部服务。我想通过制作我只能将其视为“缓冲区”来定期检查该外部服务的“缓冲区”，以减少我的应用程序对他们的服务进行的调用，并使用任何可用的新数据的副本进行更新，然后使自己直接提供给我的WebApp。
谷歌搜索后：看来我可以使用
- 协议缓冲区；这似乎是过分的，我的理解是，对于时间密集型应用程序，
- 服务队列
- 服务
之间的大量数据传输是更好的选择。我在完整的堆栈应用程序中很自学，到目前为止，关于如何在概念层面设计系统方
I'm still learning how to use API's and would like to know what the wisest way to approach taking what I have ("A" in the diagram below) and refactoring it into what I'd like to have ("B" in the diagram below).
The main idea is that my current webapp reaches directly out to an external service via (their) API. I'd like to reduce how many calls my app makes to their service by making what I can only think of as a "buffer" that will periodically check in with that external service, update itself with copies of any new data available, and then make itself available directly to my webapp.
After some googling: It looks like I could use
- a protocol buffer; This seems like overkill and my understanding is that this is better for time-intensive applications with heavy data transfer between services
- a queue service
- a message service
Any ideas for where to start would be greatly appreciated! I am largely self taught in full stack applications and there hasn't been a whole lot of guidance up to this point regarding how to design systems at a conceptual level
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
设计将取决于每个API请求的数据量，请求率等。
一种可能的解决方案是使用 tremal.io 开源项目，该项目将允许将逻辑实现为简单的代码。临时服务将使应用程序分发和弹性。
The design will depend on the amount of data per API request, the rate of requests, and so on.
One possible solution is to use temporal.io open source project which would allow implementing your logic as a simple piece of code. The Temporal service would make the application distributed and resilient.