我想设计一个应用程序，其中后端不断轮询不同的传感器，而前端（sinatra）允许通过json api查看这些数据，或者只是在html中显示结果。
我应该采取哪些措施来开发此类应用程序，以及如何构建应用程序以实现最佳扩展和易于维护。
我的第一个想法就是让Sinatra每次收到对正确终点的请求时都会对传感器进行轮询，但这似乎可能会让人感到安静，特别是看到有些传感器每隔几秒才会自动更新一次。 / p>
我的第二个想法是让后台进程（或线程）轮询传感器并存储sinatra的值。收到请求后，sinatra可以简单地在后台进程中查询缓存值（或从线程代码中提取）并将其呈现给客户端。
我更喜欢第二个想法，但我不确定如何开发“后台应用程序”，以便sinatra可以轮询它以向客户端呈现数据。另一个选择是sinatra线程传感器轮询代码，这样它就可以在同一个进程中从中获取值，而不是从另一个进程请求它。
请注意，此应用程序还将负责不同继电器的自动化，并且基于传感器，sinatra仅负责将传感器的状态转发给用户。我认为将后台进程/守护进程中的后端（自动化+传感器信息）与前端（sinatra）分开是理想的，但我不确定如何获取sinatra的数据。
任何人都有关于如何构建此内容的任何意见？如果可能的话，我也会感谢一个示例应用程序，它只显示我可以采用和修改的想法。
由于
修改::
经过一番研究后，我发现drb（分布式ruby http://ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html）允许您通过网络对对象进行远程调用。这可能是解决此问题的合适方法，因为守护程序可以自动化继电器，读取传感器并将值存储在类对象中，然后通过drb显示类对象，以便sinatra可以调用远程对象上的getter来获取来自守护进程的日期数据。这是我最初想要尝试做的事情。
你们觉得怎么样？这对于这样的申请是否可行？
答案 0 :(得分：0)
我决定选择Sinatra，DRB和Daemons来满足我上面提到的要求。
Web前端将在其自己的进程中运行，并且仅通过DRB与后端的交互来提供统计信息。这将允许客户端的快速响应时间，并允许我将前端代码与后端代码分开。
后端将在其自己的进程中运行，并不断轮询传感器以获取更新，并将它们作为带有getter的类对象存储，以便Sinatra可以在需要时通过DRB获取信息。它还将使用收集的信息进行项目特定的自动化。
最后，后端和前端将使用Daemons包装器进行包装，以便项目具有启动，重新启动，停止，运行状态以及自动重启守护进程的功能，如果它出于任何原因崩溃或退出。 / p>
来源信息：
http://phrogz.net/drb-server-for-long-running-web-processes