Dockerized Flask App-具有持续运行脚本的Rest API

Question

我有一个在本地运行的dockerized Flask应用程序，该应用程序由多个REST API端点组成。 一切都按预期工作，因此在其中一个端点上执行GET请求时，将从Postgres数据库中检索数据，然后将其显示为json。 大。 到目前为止，数据库只是测试数据，现在我需要不断用真实数据更新数据库。

我有从网络提取数据的脚本，而且我了解了如何使用发布和放置请求将其添加到数据库中，但是我不了解的是如何以及在何处连续运行此脚本，以及在何处连续运行不会干扰我服务器的REST API部分，反之亦然，几乎就像它是后端中一个完全独立的实体一样。

为此，我是否要创建一个全新的flask应用程序，该应用程序在其自己的服务器上运行，并不断运行脚本并将已抓取的数据添加到数据库中，以便其他包含API端点的flask应用程序可以在需要时访问它？ 我觉得自己离这里还很遥远，并且对于最好的前进方式的任何投入都深表感谢。 谢谢！

Answer 1

在我看来，您一点也不遥不可及。

我要说的是，让您的API自己站起来-作为数据库的网关。 在它自己的容器中。

您要执行的抓取是另一个过程-请勿将其混入flask API应用程序中。 相反，由于您已经在docker领域中，请考虑创建另一个将为您进行抓取的映像。 这可以是bash脚本，python应用程序-这并不重要。 只要您可以使其尽可能简单即可。

您甚至可以考虑是否可以以这种方式制作该应用程序/脚本映像，从而可以并行运行其中的多个映像。

是的，您将需要维护两个图像。 但是它们各自将变小，并且变得不那么复杂。 而且，如果操作正确，则可以根据需要扩大活动范围。

考虑一下UNIX哲学的前两个陈述：

1. 使每个程序都做好一件事。 要完成一项新工作，请重新构建而不是通过添加新的“功能”使旧程序复杂化。
2. 期望每个程序的输出都将成为另一个程序（尚不为人所知）的输入。 不要将多余的信息弄乱。 避免严格使用列或二进制输入格式。 不要坚持交互式输入。

可维护性是软件开发游戏中的王者。 从长远来看，杂乱无章的大型项目很难生存。

经过思考：如果您的项目是实验性的，而您只想证明一些概念，那就这样做。 并且不要过度思考设计。 太多的项目也因此而死！

至少那些是我的想法。