Angular Frondend app with multiple 'decoupled' modules

Hi, from the documentation I'm having difficulty understanding the relationships between subscriptions, topics, items, fields, etc. We have a typical scenario.

1. An Angular app ('parent') with various modules all written by one group of developers.
2. This parent app subscribes to ONE topic. here's psuedocode:
   
   1. const client = Lightstreamer.LightstreamerClient(lsServer, adapterSet)
   2. ....client.xxx = yyy, etc
   3. const item = 'json::: + strTopic + '::::${some string} + user + '\')
   4. const subscription = new Lighstreamer.Subscription('RAW', [item], '['Body']);
   5. ....

Now add a NEW LAZY LOADED module ('child') that is built by another group of developers which has it's own topic/subscription (which?requirement with a different data structure and subscription/topic(?)
Question: what are the minimum maximally decoupled lightstreamer steps, the child must carry out to get the resources to the get new topic info? please consider two possibilities:

1. IDEAL: the child is not aware of the parent lighstreamer resources so needs access to them somehow to avoid duplication and then carry out getting new topic info OR
2. OK: the parent and child share a minimal state service where the parent can share minimal info with the child while maintaining maximum decoupling and maximizing resource use (no new sockets, etc)

Thanks!

Hi,
If the modules are all part of the same page, they can share a pointer to the LightstreamerClient object and each one can use the same object to add its subscription requests, together with its listeners.
But there is no lookup method by which a module can see if there is already a LightstreamerClient object in the page. This should be implemented at application level.

On the other hand, the current Javascript SDK library provides a mechanism to share a single connection among multiple LightstreamerClient objects.
In this way, each module can create a local object, then issue enableSharing before connect(). The only common information needed between the modules is a "share name". Then Lightstreamer will try to serve all LightstreamerClient objects with the same share name with a single underlying connection. If the modules are all part of the same page, this is always possible.
The drawback of this feature is that it will not be kept in future upgrades of the SDK.

We hope that the above is in the direction of your requirements. If yes, we can expand. Otherwise, please clarify.

Yes, your response broadly addresses my question. But to be specific:

Quote:

---

If the modules are all part of the same page, they can share a pointer to the LightstreamerClient object and each one can use the same object to add its subscription requests, together with its listeners.
But there is no lookup method by which a module can see if there is already a LightstreamerClient object in the page. This should be implemented at application level.

---

So the parent module has done the following:

1. It subscribes to ONE topic 'parentTopic'. here's pseudocode:
   
   1. const client = Lightstreamer.LightstreamerClient(lsServer, adapterSet)
   2. ....client.xxx0 = yyy, etc
   3. ....client.xxx1 = yyy, etc
   4. const item = 'json::: + 'parentTopic' + '::::${some string} + user + '\')
   5. const subscription = new Lighstreamer.Subscription('RAW', [item], '['Body']);
   6. .client.subscribe(subscription)

The child module needs to create/subscribe to ANOTHER topic say ('childTopic') which receives another set of data with a different structure.

I assume, the child module just needs the handle of the client the parent has created (see 'client' above) and nothing else. If so (or not so) What are the EXACT sequence of steps for the child module to subscribe to its 'childTopic'?

Thanks!

I assume that
const client = Lightstreamer.LightstreamerClient(lsServer, adapterSet)
stands for
const client = new Lightstreamer.LightstreamerClient(lsServer, adapterSet)

Also from your citation I assume that you are not interested in Lightstreamer connection sharing feature and you opt for the sharing of the pointer to the LightstreamerClient object.

So, the code of the child module should be similar to the code of the parent, but for the first line:
instead of
const client = new Lightstreamer.LightstreamerClient(lsServer, adapterSet)
it should need something like
const client = myParent.client
where by myParent.client I denote the client object that was created by the parent module.
That said, I cannot specify how this pointer should be determined exactly, as it depends only on your code.

However, your pseudocode hides an important point: the Subscription object should be provided with a listener, through addListener.
The listener is needed to have the code consume in some way the data flow associated with the subscription.
So, both the parent and the child modules will specify a local listener object and this is how each module receives the data it subscribed to.

I can't even run a simple instace. I get an error "cannot find name 'Lightstreamer' at:
I am using version ^7.3.2 in package.json.

I see some odd references to adding lighstreamer.min.js to assets folder in your demo example. Isn't this a normal npm install?

Yes, omited a 'new' and I *do* have a listener that I neglected to post. So correction:

1. const client = new Lightstreamer.LightstreamerClient(lsServer, adapterSet)
2. ....client.xxx0 = yyy, etc
3. ....client.xxx1 = yyy, etc
4. ...client.addListener(...)
5. const item = 'json::: + 'parentTopic' + '::::${some string} + user + '\')
6. const subscription = new Lighstreamer.Subscription('RAW', [item], '['Body']);
7. .client.subscribe(subscription)

Please clarify the relation of your last problem with the use of decoupled modules.
As it is expressed, the last problems seems a problem of integration of Lightstreamer in Angular and to apply to your code as a whole.
Could you replicate our Angular demo and see it working?

Unfortunately, for help on Angular integration I have to consult my colleagues, which may require a few days.
For now, I can confirm that the instructions in our Angular demo specify that Lightstreamer SDK library should not be installed via npm, but it should be copied among the demo files. Then, other non-Lightstreamer resources, as reported in the package.json file, should be installed via npm.
Do you mean that this integration technique is incompatible with Angular modularization?

I finally have it working. Note, we are behind a corporate firewall and can’t access external repos. What I have gathered from the docs link you shared though is the simple npm install isn’t a thing and some minified file has to be installed in an assets folder which is unusual. In fact, that was the exact problem I was facing and I had to copy over the client min file from another internal app’s node modules. That’s not normal at all and has little to do with advanced notions of modularity. Simple npm installations are not new and at least a decade old. All your examples as such are problematic if they don’t adhere to this very basic notion.

Anyway, it’s still not clear what the correspondence between client, subscription, and topic is or what is recommended and why? Is it correct you can have multiple subscriptions to a client? What about topics? One topic per subscription or multiple or why? It would be great if the documents show a modern simple client subscriptions topic example with a standard npm install instead of rather old html script js references (I don’t see a simple angular 2 (13.x now) example step through clearly.

Given your responses above, my next questions will be on performance. Everything is frontend angular btw. Many thanks.

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!

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

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.

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')?

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

Thanks. Very helpful. As for:

Quote:

---

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!

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

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.

Hi Megabyzus,

As I said before it is not the expected behavior.
It is very strange that a subscribe call causes the failure of the connection attempt.

I think you need to investigate further with the client library debug log.
To enable the logging, you should add to your code the following lines:

var log = new SimpleLoggerProvider();
log.addLoggerAppender(new ConsoleAppender("DEBUG", "*"));
LightstreamerClient.setLoggerProvider(log);

For instance, you can add them before the initial creation of the instance of LightstreamerClient.

Regards,
Giuseppe

Thanks. And thoughts on '2'?:

Quote:

---

2. I'm confused now about the CONNECTED prefix. What should I look for if at all for a guaranteed connection? Shouldn't I care if there's a connection anyway before doing anything else like subscribing?.

---

Hi Megabyzus,

The 'CONNECTED' prefix actually guarantees that a physical connection with the server has already been established.
Only in the 'CONNECTED: STREAM-SENSING' case, which should be a quick transient, the client library is still evaluating the most suitable transport (Websocket, HTTP-Streaming, or polling) to use for the client session depending on the network conditions of the client.
Anyway please double check the documentation for all the casistics: https://sdk.lightstreamer.com/ls-web...onStatusChange

Finally, please let me stress out again that for subscribe requests you should not care about the status of the LightstreamerClient.

Regards,
Giuseppe

Thanks. I'll look into that further. I have all this working nicely and in the final optimization steps of the code. So:

1. Given we get a subscription object via

Quote:

---

let subscription = new Subscription(subscriptionMode, items, fields)

---

is there a way to do a reverse look up to get a subscription based on a given item? I.e.:

Quote:

---

let subscription = new GetSubscription(item)
(see NOTE 1 below for my solution)

---

2. Similarly, if I RE-subscribe to the same EXACT 'items' array above do I get the same subscription reference or a new one?

The reason for this, as always, is decoupling. In this case, I've already decoupled various modules of the app to use the same Client instance (vertical decoupling) and if no CLIENT exists to create their own.
Similarly, I'm also decoupling the UI components inside the module to not be concerned with their stream or subscription source (in this case Lightstreamer and Subscription) which is 'horizontal decoupling' within the module. The most the UI components know about is a string (we internally call a 'topic') where a separate decoupled service can construct an 'item' from that 'topic' to pass to a

Quote:

---

let subscription = new Subscription(subscriptionMode, createItem('topic'), fields).

---

Similarly when the UI component is destroyed it will unsubscribe('topic') as its last act--it knows nothing of Clients or Subscriptions or Lightstreamer and only knows the 'topic' string. I ideally do not want to manage my own Map<topic, subscription> internally OR pass the subscription handle or any other LS artifacts to the UI components.

NOTE 1: Given the documentation, reverse look-up can be done by the following psuedocode;

Quote:

---

let subscriptions = _lightstreamerClient.getSubscriptions()
for (subscription in subscriptions) {
let items = subscription.getItems()
for (item in items) {
if item.includes('topic') exit both loops with found subscription object...
}
}

---

NOTE 2: For your reference, I'm managing that decoupled service using an NgRx state machine.

Thanks.

Hi Megabyzus,

Thank you for the feedback about your integration process.

About your questions:

1. I can confirm that the combination of getSubscriptions and then getItems, as per your pseudocode of NOTE 1, is a good solution since there is no direct method that returns the set of active subscriptions for a given list of Items.

2. No, if you call subscribe with the same parameters (mode, items list and fields list) of a previous one the LightstreamerClient will create a brand new subscription in addition to the old one.
Basically you will receive the same data twice.

Regards,
Giuseppe

Quote:

---

Originally Posted by giuseppe.corti

Hi Megabyzus,
1. I can confirm that the combination of getSubscriptions and then getItems, as per your pseudocode of NOTE 1, is a good solution since there is no direct method that returns the set of active subscriptions for a given list of Items.

---

Thanks. To be clear, since there is no 1 - 1 correspondence between items and subscriptions (i.e. we can have multiple subscription references to the same items and vice versa) then my pseudocode needs to be modified to return an array of subscriptions for identical items. Then those array elements need to be individually unsubscribed. In other words, questions 1 & 2 in my mentioned post were related.

Thanks!