Thinking ahead in the future... we will need to implement SignalR for handling certain use-cases.
At some point we will have the challenge-service integrated here. For processes that are long-running on the server side we cannot expect a user to sit idle on a page waiting for a response. By offloading the response to realtime-comms we can consume the response whenever it happens without sacrificing responsiveness of the frontend.
For certain pages we may also update contents in "real-time" indicating new posts that were made --- instead of having to refresh to see new content.
That being said we need to lay the groundwork for making it easy to implement these real-time communications where needed.
Thinking ahead in the future... we will need to implement SignalR for handling certain use-cases.
At some point we will have the challenge-service integrated here. For processes that are long-running on the server side we cannot expect a user to sit idle on a page waiting for a response. By offloading the response to realtime-comms we can consume the response whenever it happens without sacrificing responsiveness of the frontend.
For certain pages we may also update contents in "real-time" indicating new posts that were made --- instead of having to refresh to see new content.
That being said we need to lay the groundwork for making it easy to implement these real-time communications where needed.