7

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.

Improve this question
2
  • There are loads of different ways to acheive this. Which is suitable depends on your use case and what trade offs are important for the application. A first person shooter video game client is not going to communicate to a server in the same fashion a website like Tinder will. Can you be more specific in your question as to what are the criteria that matter here
    – Cormac Mulhall
    Commented Nov 14, 2019 at 11:58
  • Do you have any control over the API layer? That makes a huge difference.
    – Kyle J V
    Commented Nov 16, 2019 at 1:00

4 Answers 4

Reset to default
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.

Improve this answer
1

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.

Improve this answer
1

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

Improve this answer
0

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.