Modular service architecture

As per the original request in post: RoasTime Hot Keys / Quick Keys / Streamdeck…, there are two natural paths one might take to achieve the modular architecture suggested:

  1. The complicated approach, and most flexible, is to introduce a service layer that interface with the roaster. RoasTime then connects with that service layer through an API (REST or other). Advantages of that approach is to be able to operate multiple roasters on a network using decentralised RoasTime consoles. A 3rd party application could then consume the same API (Cropster or Firescope or something entirely different)… not to mention what it’d do for the AiO.

  2. A less complex solution, and one that really isn’t that difficult to implement already, is to publish roaster metrics through an API exposed by RoasTime itself. That will require the application to run as it does today, but will allow other programs access to live roasting data.

Either approach would be exceptionally helpful in attaching other applications to a roasting workflow. For instance, I currently feed a spreadsheet from the JSON files in RoasTime, to populate roasting logs (Excel power queries to the rescue) - but there is so much more that I would love to have available.