Use device as a socket client instead

[blackchineykh]

There are cases where synchronous messaging would be good. The design for this could be done using the device as a socket client and the server as a socket server with multiple clients registering themselves as devices and have keep alives going. Using the server as a nodejs backend with Promises, requests to send sms can then be handled synchronously. Other request types can also be done this way, for example USSD. Thoughts?

[capcom6]

Hello and thank you for your proposal.

The main reason for choosing asynchronous communication is to limit battery usage on devices. Not all devices with the app are always connected to a charger. By using push notifications, the time between the message being received by the cloud server and the device sending it is measured in seconds. This is sufficient even for short-lived messages like OTP codes. Near-synchronous communication can be achieved in local server mode, at least for sending messages.

With synchronous communication, under ideal conditions, the time between an API request to send a message and the app receiving it on the device would be less, perhaps milliseconds. However, there are some potential issues:

1. Decreased battery life due to the need for a persistent connection.
2. No guarantee of consistent functionality due to OS battery optimization. The connection can be closed at any time if the app is in the background.
3. There may be issues with some environments, for example, behind proxies.
4. Handling persistent connections requires more resources from the server.

Can you describe your use case and any problems you've encountered with the current architecture in detail? If you prefer not to share this information here, you can email me at [email protected].

However, I'll test this idea if I have enough free time.