Should the API calculate events instead of FBOS?

[roryaronson]

Currently FBOS handles the calculation of repeating event instances and when regimen items should run. Historically, this has been temperamental, and very time-consuming and tedious to manually QA because you have to use an actual bot and wait a real amount of time between executions. @ConnorRigby, correct me if I'm wrong but I think you've also cited that writing automated tests for this on the FBOS side would be difficult because of the amount of fixturing(?)/state to build up to test each scenario (and there are a lot of scenarios when taking into account update actions) whereas this would be much more testable on the API side of things.

I brought up the idea a few months ago to move event calculation from FBOS into the API. If this were done, FBOS would sync something like the expanded form of events/regimens (which is basically always reduced down to something like a sequence running at a specific time, with optional variable inputs). Then those events would be put onto some kind of master queue in FBOS.

Some potential upsides to this:

• In theory (and the main reason I think we would do this) is we would be able to improve test coverage because writing tests would be easier on the web side (cc @ConnorRigby @RickCarlino this is just what I've gathered from talking with you, please correct if wrong)
• We would offload more CPU tasks from FarmBot, which may be a substantial performance improvement for Pi Zero based devices with lots of events
• We've talked about ways for users to see/verify if a specific event instance actually executed or not. It would probably(?) be easier under this architecture for FBOS to report that and for the API to track/store that info. We could add ✅and ❌ indicators in the FE next to past events showing if they completed successfully or not.
• It would probably(?) be easier for FBOS to report what it is currently executing.
• Repeating event instance calculation could be removed from the FE as well?
• What else?

Some potential downsides:

• Increased data transfer for syncing, but maybe that is negligible?
• FBOS would need to sync at least one year worth of calculated events, otherwise we're eating into the usefulness/prospect of running a bot offline for extended periods of time. Two full years would probably be better, but that would be a max of about 1M events 😬 (one per minute).
• If a Farmware wanted to add or change an event or a regimen on-device (are either of those things even possible?) it would need to handle the calculations.
• What else?

Some questions:

• Would this architecture be more "future-proof", or is the existing architecture better in that regard? ie: are there any features we've talked about that would not be possible if this change were implemented?
• What's the timeline look like for such a change?
• What other features have we talked about that would be much easier to develop under this architecture?
• What's the real performance loss/gain trading out CPU for Sync Data?
• What's the cost to us to calculate all user's events on our servers?
• How will latency change between saving an event/regimen and FarmBot being ready to execute?

[RickCarlino]

If a Farmware wanted to add or change an event or a regimen on-device (are either of those things even possible?) it would need to handle the calculations.

Possibly. Creating prototype data structures would be helpful.

Other things we will need to know:

• why does a specific instance exist? Example: "Instance 123 is part of sequence X, under regimen Y, executed by farm event Z".
• how was a specific incidence handled and why. "Instance 456 was skipped because FarmBot was not able to get to it within 5 minutes".

Action items:

• Create some prototype data structures to support this.