[General Discussion] Handling socket events efficiently

Help General
1

Hey all,

I am working on a trading app and we have a lot of socket connect to show live market data. Now I want to manage it efficiently e.g when the user switch from a socket connected screen to non-socket connected screen. Should I pause/resume the StreamSubscription? Should I cancel the socket connection and reconnect once the user visit back the screen?

The idea is to keep the usage of the app fast and performant.

2

Good question, this is a common challenge with live data apps. If your socket connection is resource-heavy, closing it when the user navigates away and reconnecting on return is a safe choice. However, if reconnecting takes time or impacts UX, you could pause the StreamSubscription instead and manage data flow based on screen visibility. A centralized socket manager can help maintain the connection in the background while controlling what data reaches active screens. Just be mindful of potential stale data or state inconsistencies when switching between screens.

1 Like
3

Disclaimer: I work years for or with the Ibovespa (the SĂŁo Paulo stock exchange - one of the largest exchanges in the world in terms of market value, the second largest in the Americas, and the leading exchange in Latin America.), basically crating home brokers and related stuff.

  1. That kind of speed is useless for this scenario (I worked with so many people that think performance was needed, but they forget the monitor is only 60Hz and most people could not even see some changes after 24Hz, so why in the hell do you need a stock to updates 1000x per second? It only wasted bandwidth and RAM. It is a VERY concurrent market (no pun intended), so, you don’t need to flood your app with so much information that will be discarded anyway >.<))

  2. MQTT. It’s light and fast, made for IOT (meaning: is light on resources). Since you can subscribe/unsubscribe channels at will, you can leave an open connection through all your app lifecycle and start receiving data as needed (considering that some stocks could have a huge delay in this scenario if no trades are being made on those, but you can always ask for an initial value, it all depends on your SE APIs).

2 Likes
4

I agree with your points. I have the ability to define delay at which frequency I want the data from BE. I would like to know what all optimizations or design techniques you have used to give a better experience to the users.

I will definitely look into MQTT but feels like it will require time to implement as it’s not just for frontend but backend too.

5

I would probably use a central service/manager that keeps the connection as long as the app is in the foreground and let that service publish and cash it’s data as ValueNotifiers which I think are easier to consume in the UI in most cases.

So your UI will not have to deal with to keep past data but can be stateless and just pull data from your service/manager

1 Like
6

Basically, you have channels. For instance, you can publish one stock per channel (or a group of stocks, you define). The server just publishes them. The client pick what they want to receive, by subscribing to that channel.

In the UI level, you can create widgets that listen to certain channels, so your entire screen can be really made of tiny components that deals only with what they are displaying.

Yes, but, in the end, it will make your life easier. Instead of using one socket and having a huge controller that sees and deals with everything, you can go “microservices style” on your network layer and UI. It is worth the time (of course, if you are no under pressure, like most projects out there that have very nice and understanding managers and no pressures at all from customers or stake holders, I’ll shut up now =P).