I appreciate your response, and don't want to go too far off the thread here, but as a software developer/architect myself, how can that possibly be true?
The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection.
This would be the same mechanism a local-first connection would use, right? What am I missing here?
Aside from all the small added complexities of swapping between local http polling vs mqtt pub/sub for both apps and devices, the big complexity is managing authorization. Think about how simple the device firmware gets to be if the only access pattern is a single secured mqtt channel for processing commands. Anything coming down that pipe comes from a cloud provider that has already negotiated who can and can't send those commands. When you open up local access the device itself now needs more code to manage authorization and all the attack surfaces that come along with that.
The state of the environment that the IoT device is sensing or controlling, has to match local reality. Therefore, the state that's actually on the IoT's MCU is the true state that matters. (Any state stored cloud-side could be stale if the MCU is disconnected, or misses updates) Ergo, if the cloud service is showing or manipulating the state of the IoT device, it has to read or command the IoT in near realtime, implying some kind of constant/realtime connection.
This would be the same mechanism a local-first connection would use, right? What am I missing here?