Angular Frondend app with multiple 'decoupled' modules

[Megabyzus]

Excellent. Multiple subscriptions clears a lot for us. Many thanks. A few related questions:

1. In terms of performance, since there are TWO particular pages that are interested in their separate subscriptions, once a client connection is established, is it ok to keep it and merely subscribe and unsubscribe on page entry and exit when needed or should the connection be cut too?
2. In terms of performance, since there are TWO particular pages that are interested in their separate subscriptions, should we subscribe and unsubscribe on page entry and exit or can we keep the subscriptions open?
3. We are subscribing using the 'RAW" mode. However, the data comes back in a particular key 'Pd' where we extract it. Is there a more elegant way we can receive data and not rely on an esoteric key ('Pd')?

[giuseppe.corti]

Hi Megabyzus,

1. I can confirm that generally it is a good practice to keep the LightstreamerClient object connected to the server and subscribe and unsubscribe dynamically accordingly with the user navigation.
A possible scenario in which disconnecting the LightstreamerClient may make sense, is if you are aware that the client has entered a state where no communication at all is expected with the server for a long time (several minutes or more).

2. Again it depends on the application scenario, it is generally advisable to unsubscribe when you exit the page and the data is no longer displayed (otherwise you would continue to receive useless data).
But you could choose the opposite behavior if for example there are not so many real-time updates instead the initial image (the snapshot) is very large.

3. The RAW mode is quite particular and implies giving up some optimizations and features of the others.
But unfortunately I didn't understand enough about your data model, to give you any further suggestions.
Do you mean that your subscriptions have only one field called 'Pd' which contains the whole message?
Could you expand a bit more on what the messages received from the client contain?

Regards,
Giuseppe

[Megabyzus]

Thanks. Very helpful. As for:

3. The RAW mode is quite particular and implies giving up some optimizations and features of the others.
But unfortunately I didn't understand enough about your data model, to give you any further suggestions.
Do you mean that your subscriptions have only one field called 'Pd' which contains the whole message?
Could you expand a bit more on what the messages received from the client contain?

I'm not sure if this is our construct. I thought it was yours. However, it seems from your response it is ours. I'll look into it.

Other questions:

I noticed if I try to subscribe while the client is connecting the connection status message listener ceases. So:

1. Does this mean the client has ceased connecting?
2. If so, are ALL the messages that include the text 'CONNECTED:' a valid client connection or just the ones like 'WS STREAMING', ''HTTP STREAMING'? Are the 'POLLING' messages considered connected and can I subscribe or no? NOTE: I'd rather just check for a string containing 'CONNECTED' than be specific. Or is there a specific connected message I can listen for sent by the client object?

Thanks!