Understanding TypeScript OSDK Subscriptions

Ask the Community
1

I’m currently working with the TypeScript Ontology SDK (OSDK) and exploring the subscriptions feature as documented here: Subscribe to Ontology changes with the TypeScript OSDK. While the documentation provides a good overview of how to set up subscriptions to receive updates when objects in a specified object set change, I’m curious about the underlying mechanics of how these subscriptions operate.

Specifically, I have a few questions:

  1. Mechanism of Receiving Updates: When I set up a subscription in my OSDK application running as a web server, how does it actually receive updates? Is the SDK employing a polling mechanism under the hood, or are updates pushed to the application in real-time?
  2. Reliability and Guarantees: What guarantees does the OSDK provide regarding the delivery of updates? For instance, is there a possibility of missing updates if the application experiences downtime, or does the SDK handle reconnection and state synchronization to ensure consistency?
  3. Cleanup and Subscription Management: The .subscribe() method returns an object with an unsubscribe() function. I’m interested in understanding how the cleanup process works, especially in scenarios where the application crashes or is terminated unexpectedly. Do I need to implement a mechanism to track and manage subscriptions, perhaps storing them in a database, to ensure that there are no lingering subscriptions or resource leaks on the server side?

Understanding these aspects is crucial for me to design my application architecture effectively and ensure data consistency. If anyone has insights or experiences to share regarding the internal workings of OSDK subscriptions, I would greatly appreciate your input.

Thanks in advance!

2

Hey! I can address some aspect of these questions for you from the javascript perspective.

  1. Its a simple websocket connection pushing results in real time. We utilize sharing the websocket if there are multiple subscriptions active. Example: if you create 3 subscriptions, you should see one socket. If you unsubscribe from all of those then the socket will clean itself up after a short period of being unused.
  2. From the javascript side, a small window of low signal would generally mean TCP/IP ensures the packets are delivered. Anything bigger than that, like full signal loss / reconnect of the network stack, would result in a disconnect. There are 2 callbacks on the Listener you can provide that are going to be relevant to you. onOutOfDate could occur for a variety of reasons related to backend connectivity (failover, blue-green deployments, network loss, cache blowout, etc) and the jsdoc states that your object set should be re-fetched in its entirety. There is also an onError callback on the listener that states There was a fatal error with the subscription process. The subscription will close or will not be established. In either case, there are no guarantees and you should resubscribe and refetch the data.
  3. The backed manages its own cleanup based on connection status. If your process ceases to run, the network connection will be closed and the backend will cleanup its resources accordingly.
3

Thanks so much for the detailed explanation.

I’ll make sure to leverage the two callbacks and it’s great to know that the backend handles cleanup based on connection status, and I don’t need to persist subscription state externally.