Page 1 of 3 123 LastLast
Results 1 to 10 of 21
  1. #1

    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!
    Last edited by Megabyzus; April 11th, 2022 at 10:30 PM.

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,047
    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.

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

    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!

  4. #4
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,047
    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.

  5. #5
    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)

  6. #6
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,047
    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?

  7. #7
    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.
    Last edited by Megabyzus; April 16th, 2022 at 01:49 AM.

  8. #8
    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!
    Last edited by Megabyzus; April 18th, 2022 at 09:43 PM.

  9. #9
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    664
    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

  10. #10
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,047
    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.

 

 

Similar Threads

  1. Replies: 27
    Last Post: October 21st, 2020, 10:30 AM
  2. Replies: 6
    Last Post: July 11th, 2016, 09:27 AM
  3. Replies: 3
    Last Post: August 16th, 2011, 10:39 AM
  4. J2EE app to push message via LS w/o JMS
    By atamel in forum General
    Replies: 3
    Last Post: August 9th, 2010, 02:09 PM
  5. Replies: 1
    Last Post: November 18th, 2009, 09:44 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 12:20 AM.