Because the client has its own infrastructure and backend already mounted. Although on my thoughts it could be a middleware between the actual nodeJS and the ESP32, but the client does not want this solution, they want something more clean based in what they have actually (that does work)
They have chosen ESP32, because it very difficult to corrupt, not the case with their actual hardware on RPI, which the SD is very volatile, although we have managed to lower the risk by putting the whole SD as read-only, except for a couple of dirs mounted on RAM. This works well, but the mess comes up when there is a shutdown, then power comes back, and when the RPI is at boot stage, if there is another power loss, the SD has a very high change of getting corrupted.
We also looked at Android Things, which has a very reliable SD protection system, but Android is becoming very unstable, they restricted for 100 devices, maintain only legacy support, etc. Client stations are located in the middle of the mountains range in Chile, so changing the OS for 180 units up in the mountains it´s not an easy task.
So we come down that every solution has it downside, and that’s why we were looking on the file system robustness of the ESP