0

I am wanting to design an application where the back end is constantly polling different sensors while the front end (sinatra) allows for this data to be viewed either via json api, or by simply displaying the results in html.

What considerations should I take to develop such an application and how should I structure the application for best scaling and ease of maintenance.

My first thought is to simply let sinatra poll the sensors every time it receives a request to the proper end points, but this seems like it could bog down quiet fast especially seeing how that some sensors only update themselves every couple seconds.

My second thought is to have a background process (or thread) poll the sensors and store the values for sinatra. When a request is received sinatra can then simply poll the background process for a cached value (or pull it from the threaded code) and present it to the client.

I like the second thought more, but I am not sure how I would develop the "background application" so that sinatra could poll it for data to present to the client. The other option would be for sinatra to thread the sensor polling code so that it can simply grab values from it inside the same process rather than requesting it from another process.

Due note that this application will also be responsible for automation of different relays and such based off the sensors and sinatra is only responsible for relaying the status of the sensors to the user. I think separating the backend (automation + sensor information) in a background process/daemon from the frontend (sinatra) would be ideal, but I am not sure how I would fetch the data for sinatra.

Anyone have any input on how I could structure this? If possible I would also appreciate a sample application that simply displays the idea that I could adopt and modify.

Thanks

Edit::

After a bit more research I have discovered drb (distributed ruby http://ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html) which allows you to make remote calls on objects over the network. This may be a suitable solution to this problem as the daemon can automate the relays, read the sensors and store the values in class objects, and then present the class objects over drb so that sinatra can call the getters on the remote object to obtain up to date data from the daemon. This is what I initially wanted to attempt to do.

What do you guys think? Is this advisable for such an application?

randy newfield
  • 1,221
  • 3
  • 25
  • 38
  • You should use websockets for bidirectional communication. It will remove the necessity to poll entirely. I recommend [faye-websocket](https://github.com/faye/faye-websocket-ruby) – max pleaner Feb 25 '17 at 22:58
  • @maxple I found `DRB` and edited part of my question. Do you think DRB is advisable to be used with sinatra? Ideally I am looking for a way to get data from a remote process easily so that sinatra running in another process can present the data to the client. – randy newfield Feb 26 '17 at 00:03
  • I didn't know about DRB, so I don't know. But you can use websockets for server<=>server communication too (if you can run a webapp on your sensor machine) – max pleaner Feb 26 '17 at 02:37

1 Answers1

1

I have decided to go with Sinatra, DRB, and Daemons to meet the requirements I have stated above.

The web front end will run in its own process and only serve up statistical information via DRB interactions with the backend. This will allow quick response times for the clients and allow me to separate front end code from backend code.

The backend will run in its own process and constantly poll the sensors for updates and store them as class objects with getters so that Sinatra can fetch the information over DRB when required. It will also use the gathered information for automation that is project specific.

Finally the backend and frontend will be wrapped with a Daemons wrapper so that the project will have the capabilities of starting, restarting, stopping, run status, and automatic restarting of the Daemons if it crashes or quits for what ever reason.

Source information:

http://phrogz.net/drb-server-for-long-running-web-processes

http://ruby-doc.org/stdlib-1.9.3/libdoc/drb/rdoc/DRb.html

http://www.sinatrarb.com/

https://github.com/thuehlinger/daemons

randy newfield
  • 1,221
  • 3
  • 25
  • 38