For Surround, it’s much more complicated than that. However, a lot of the complications are due to the fact that it’s a proxy server and not OGS itself. Some examples:
- I need each client (can have multiple clients per user) to tell the server what they have seen, so that when a client has seen a move then the notification for that will not be sent to the other clients.
- I need to parse and compare OGS data on server to figure out what notifications need to be sent.
- Each client can have their own notification settings. (A real example: user can set the notifications for “time running out” to be sent to both their iPhone and iPad, while notifications for a new move to be sent to their iPad only)
It should be simpler to implement push notifications from OGS server, but still not as simple as your article. At least OGS needs to have a way for mobile clients to give them push credentials, and also needs to support multiple devices.
This is correct, I got away with it easily because I set up my server from the beginning just for push notifications, so I can use Python’s asyncio for everything. Adding this to an existing server is not a trivial task.
Also, I imagine debugging push notifications while the backend and the client are control by different parties will be quite painful…
For me, I would much prefer that OGS supports webhooks for notifications. That should be much simpler to implement and it will eliminate the majority of the complications and server cost for me already. (Another minor reason is that I am not entirely comfortable to give OGS the ability to send arbitrary push notifications to my app).
I can make push notifications in my app available to everyone for free if webhooks are supported.