Ag grid subscriptions and lazy scrolling and subscription mode

Hi,
Our users will be concurrently updating a 'shared' ag-grid client multiple cells (akin to Google sheets). A few questions:
1. How do we manage the Subscription for this grid given the list is incomplete (lazy scrolled?).
2. Is it correct to assume the data-item and data-field arrays need to be somehow dynamically managed for a Subscription? How? I see an example demo but the ag-grid list is static and known it advance.
3. What is the best subscription mode for this type of real time collaboration (RTC) and why? The MERGE or DISTINCT or... is unclear in the documentation although the example above it is set to MERGE if I recall correctly.

As a customer we're greatful for your continued and timely support and guidance. You've been very helpful.

Thanks!

Hi Megabyzus,

The list of Items (and also the list of fields) in a Subscription request is something that can not be changed dynamically during the life cycle of the subscription.
So, it would be necessary every time there is a change in the Item list to call unsubscribe and proceed with a new subscription request.

However, there are actually two better ways to handle this situation:

- The first is achievable if the client has full control over the dynamics with which the list of Items (which must be subscribed at any time) changes.
In this case it is possible for the client to make different subscription requests for each Item, so that every time a new Item needs to be subcribed a new subscription request will be processed; and every time an Item is no longer necessary an unsubscribe request for the specific subscription will be issued.
The application will be responsible for associating all subscription listeners to the same graphical widget.
This option is something similar to what is implemented in this demo: https://demos.lightstreamer.com/GridDemo/

- The second option is advisable when a single client does not have control of the changes in the Items list which can also be determined by external events.
In this case, the server will keep the client updated with the list of Items currently to be displayed.
This is achieved with a COMMAND mode subscription; the client subscribes to a single Item and the server keeps a dynamic table updated with appropriate ADD, DELETE, and UPDATE commands.
This option is something similar to what is implemented in this demo: https://demos.lightstreamer.com/PortfolioDemo/

Please let me know if one of the above scenarios applies to your use-case; and maybe we can expand on it.

Regards,
Giuseppe

Giuseppe, thanks. I scanned that segment in the repo (the one with scriptaculous, right?). It seems the gid list is static and predefined. Our's is not and scrolling will retrieve new blocks of list data. Is this the same scenario?

Hi Megabyzus,

Actually in the Grid example (https://demos.lightstreamer.com/GridDemo/) the list of elements displayed by the grid is not static but changes dynamically based on user interaction.
Incidentally since it is a very basic example, the list of Items that can be viewed is hard-coded in the client but this is not the decisive point.
The precondition for using this option is that the single client (or user) is able to independently determine the list of Items even when it changes over time.

But if the changes are caused by external sources and therefore must somehow be communicated to the client, then the approach with the COMMAND mode is preferable.
It allows the server (more precisely the adapter) to collect all the events that modify the list of items to be subscribed, keep this list updated and in turn update all the affected clients.

Please also note that as an alternative to COMMAND mode it can be managed in a more basic way through a new Item in MERGE mode that simply publishes the updated list of Items to be subscribed.
Then the client has to manage the subscriptions; all work that with a subscription in COMMAND mode is done out of the box.

Regards,
Giuseppe

Giuseppe, many thanks.

I'm still a bit unclear. To reiterate, multiple users will be working on the same ng-grid. Can you explicitly clarify the following?:

- What's special about the viewport (ng-grid in our case)? For conversation's sake, let's imagine we haven't determined the list we get is static or dynamic. Regardless of either choice, why do we care about managing subscriptions on items displayed in the viewport? Why can't we manage subscription on items that the ng-grid contains (rather what's in the viewport)? In other words, why not unsubscribe from previous list and subscribe to the updated one? In the case of the static list there's only one initial subscription and that's it Why not?.

- what is the performance impact on the client repeatedly subscribing/unsubscribing/subscribing to updated lists?

- I'm looking at your ng-grid demo example here. I see MERGE subscription mode is used. Why wasn't COMMAND used? Why not DISTINCT? I'm still unclear on what the subscription mode differences are. The documentation is not clear to me. What is a good series of examples that clearly differentiate those use cases?

- is the ng-grid list above static or dynamic? I don't see any unsubscribes...

- what is a good example on a grid that is updated simultaneous by multiple users?

Again, thanks!

Hi Megabyzus,

- Yes you are right. Any consideration regarding the viewport or the widgets chosen for display should be independent from the choices regarding the mode and the handling of subscribing requests.
These should only be driven by the data model of your application.

- Continuous subscribe and unsubscribe requests can have an impact in terms of load both on the client side and on the server side.
Whether it can still be a sustainable workload depends on the frequency for each user and on the total load on the server which also depends on the number of connected clients.
But to properly assess this situation you should do some load tests in a scenario as close as possible to what you expect in the production.

- StockList is the perfect example for MERGE mode; as well as Portfolio for COMMAND mode and Chat for DISTINCT mode.
But please consider that any specific use case can better suit a mode or another based on particular needs.
So it is necessary to understand well the peculiarities of each subscription mode as described in the "3.2 Data Model and Subscription Modes" paragraph of General Concepts documentation.

- in the example above the list of subscribed items is static.

- PortfolioDemo you can open the demo from different tabs/browsers and modify the list of subscribed stocks concurrently.

Regards,
Giuseppe

Giuseppe, many thanks. For a shared collaborative grid what subscription mode do you believe is suited best and why?

Hi Megabyzus,

As I said in previous posts you can choose between various implementation options, but in general I think that COMMAND mode is to be preferred in this scenario.
In fact, this mode allows you to automatically keep updated all the clients with the changes in the list of items to be displayed.
Please consider this scenario where each client can autonomously make changes to the grid, also to add or remove a row, and communicate these changes to the adapter through for example a sendmessage.
At this point the adapter processes the changes, updates its internal state and produces the proper commands (in terms of ADD, DELETE, or UPDATE) to be forwarded in order to synchronize all the other clients.

Please let me know if this is something applicable to your use case.

Regards,
Giuseppe