Alternatives to polling an API

Question

Assume we have a desktop application (probably WinForms) that acts as a client to some API for an app with a messaging function. This API has endpoints that return a JSON of messages, and who sent them and where they sent them. A messaging feature is to be implemented in the application, so that messages can be sent and received in real-time, or close to it.

Is polling the API every second or so a good way to achieve this? According to this link: https://medium.com/tinder-engineering/how-tinder-delivers-your-matches-and-messages-at-scale-504049f22ce0, even Tinder used to do this. This is rather surprising to me, as this seems like a primitive way to go about it, for an app like this. If so, what would be the best approach, running this polling on a separate thread, if we want to do other tasks in the meantime? If not, what would be a better solution? It is preferable to be able to later re-create this application Java Swing, C++ wxWidgets, or some other widget toolkit.

Answer 1

You didn't specify what your back-end is written in, so I'm not sure if this will help or not.

If you're looking for a "high level" protocol (which is built on WebSocket), you could consider SignalR. If you use the newest version, it's cross platform (if that matters), and there's a client-side API implementation for C# available which will drop right into your WebForm application.

The advantage to using this is that it already will deal with things like "how do I handle multiple servers" and "how do I write the WebSocket code" and focus instead on solving the business problem.

The downside is that it's (very) opinionated as to how it works and the back end is .NET only. There is a Java client available, but the supported one is only if you're using the newest .Net core version.

Answer 2

An alternative would be the WebSocket protocol. Note that it needs to have an open TCP connection to the server, which might limit the number of possible sessions at a time (HTTP servers can close idle connections because the clients will re-establish them when needed).

WebSockets seems to have fallen out of favor a bit, maybe because simple HTTP servers allow for much easier failover and scaling under varying load, but for a small application with a moderate number of users it could work well.

Answer 3

The link in your question mentions Websockets as an alternative to the short polling Tinder was using. Websockets, or opening and keeping up some sort of tunnel between the server and client is the way most real-time messaging services handle client-server communication. Maybe you knew that already, maybe not. But this has been addressed in these questions and I suggest you start from there if you haven't already.

Better ways than traditional polling methods

Scalable solution for website polling

Answer 4

Use a real messaging service like RabbitMq or Azure Service Bus. The server API application posts updates to a topic and then the client (your desktop application) can be a subscriber. The subscription client keeps an open connection and receives messages as they come.