Angular Frondend app with multiple 'decoupled' modules

[Megabyzus]

While, you're kindly working on responses to my previous post, I have a separate series of questions:

1. a how many 'subscriptions'; can be made to a lightstreamer client object?
1. b. Why is this different than passing an array of items to a single subscription?
1. c. what are the frontend and backend performance comparisons of the two above?
1. d. what is the recommended approach and why (please read question '2' before responding?
2. as discussed we have different frontend modules that we need to keep decoupled. You suggested in a previous post that a client object handle must be shared since the alternative is being deprecated (this global query would've been ideal in terms of a modularized frontend?). anyway:
2.a. module 1 has already subscribed to an array of items. module 2 needs to maintain its own different items. I see the 'setItems(...) method in Subscribe(..). But I also see references to 'isActive' and 'unsubscribe'. What are the EXACT sequence of steps for module 2 to add it's own items to a Subscription given module 2 has a handle to the client object and module 1 already has a subscription to its own items (created in module 1)?
2. b. related to question(s) '1' above. Is it better for module 2 to just create a separate subscription rather than tamper with module 1's subscription? Why or why not (note performance)? This is obviously ideal since it keeps the modules maximally de-coupled.


Kindly respond to items above individually. Thanks!

[giuseppe.corti]

Hi Megabyzus,

1.a There is no limit to the number of subscriptions a LightstreamerClient object can request.
Obviously considerations regarding the performance of the client application must also be taken into account; but in this case more than the number of subscriptions the metric to consider is the total input throughput that the application can sustain.

1.b There are many good reasons to prefer multiple subscriptions over a single subscription request, and in some cases it is just mandatory to have multiple ones.
For example, if the Items you subscribe to are provided by different Data Adapters it is necessary to use different subscriptions since the Data Adapter is a unique element for the subscription object.
Even if the Items come from the same Data Adapter but require different subscription modes (MERGE, DISTINCT, COMMAND or RAW) then you have to use different subscriptions.
However, even if your case is not one of the above, there are very good reasons to still prefer different subscriptions:
- with multiple subscriptions you can dynamically subscribe and unsubscribe groups of Items, since your application does not necessarily need all the data at all times.
Think about an application managed in pages, when the user changes page you can dynamically unsubscribe the Items necessary for the old page and subscribe those necessary for the new one.
- Groups of Items need different operating parameters, for example some Items you want to receive them with a frequency of 2 updates per second others with an update every 10 seconds, this is possible by setting a different max frequency for the two different subscriptions.

1.c As I said before (point 1.a) from the client's point of view it doesn't change much, what matters is the total inbound throughput of all subscriptions. Especially considering the websocket transport making a request to the server for the client is very inexpensive.
As for the server, on the other hand, the number of requests to handle can become a potential load problem.
But you should consider the total load of the server in terms of number of clients, number of requests from the client, frequency of these requests and total outbound throughput. All this compared with the hw characteristics of the server.

2.a The correct sequence is:
1. call the unsubscribe method of the LightstreamerClient for the original subscription object
2. wait inactive state for the subscription
3. made all the changes you need (setItems, setFields, ... )
4.call subscribe method of the LightstreamerClient

2.b In a scenario like the one described I would opt to have two separate subscriptions, then leave the first subscription unchanged and create a new one for module 2.
Please consider that having multiple subscriptions is absolutely normal for real-world client applications.
Indeed, the scenario with a single subscription applies only in extreme cases where the application needs a fairly limited set of Items always with the same characteristics and for the entire duration of the life cycle.

1.d The recommended approach is a trade off which depends a lot on the type and the specifics of the application.
However let me point out that you don't have to be too hesitant to have more subscriptions, it is absolutely normal to have a decent number of subscriptions for a client.
You should only worry if the number of subscriptions is high, much higher than ten per client, and especially if the frequency with which a client requests subscriptions and unsubcriptions is very high.

Regards,
Giuseppe

[DarioCrivelli]

Please consider that Lightstreamer is a general purpose tool which is focused on the data flow management. You may have found our General Concepts document, in which we clarify the kind of services offered by Lightstreamer.
We try to make it possible to access to Lightstreamer services from all kinds of clients and in fact one of the ways to access is via a TCP connection and a custom protocol.
Then we provide interfaces on different languages that offer a more manageable logical view. For the javascript language, we also target the two different environments of browsers and nodejs with different libraries.
Our assumption is that, with the libraries we make available, we can ensure that every framework and every version of that framework can become a Lightstreamer client.

Then we try to do our best to demonstrate this claim with various demos, but we also count on the integrators to find the best way from their knowledge of the framework at hand.
In Angular case, the way we chose to integrate the javascript library in our demo may not (or may no longer) be considered as a best practice, but only as something that works. For how to leverage the javascript interface, we have nothing to add that is specific to Angular. All the degrees of freedom offered by the javascript interface documentation are available.

[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!

[giuseppe.corti]

Hi Megabyzus,

1. No, the subscribe requests should not interfere in any way with connection operations.
If a valid client session with the server is not established yet at the moment of the subscribe the requests are queued and sent to the server as soon as a good one is started.

2. No, the 'CONNECTED' prefix is no guarantee that there is an actually active session with the server, for example when status is CONNECTED:STREAM-SENSING the client session is not actually ready.
I can confirm to you that 'POLLING' is considered a well established session.
But as said in 1. you can call subscribe regardless of client status.

Regards,
Giuseppe

[Megabyzus]

Hmmm.

1. If i attempt a subscribe before a 'CONNECT: XXXX' the listener that spits out the connection status stops. I can olny make it work if indeed there is a connection.

2. I'm confused now about the CONNECTED prefix. What should I look for if at all for a guaranteed connection? I am currently unable to subscribe until there's a connection.