Skip to main content
The PubSubAdapter trait defines the interface for pub/sub messaging in III. PubSub adapters enable event-driven architectures by allowing functions to publish and subscribe to topics.

Trait Definition

Source: /workspace/source/src/modules/pubsub/mod.rs:21

Methods

publish

Publishes an event to a topic. All functions subscribed to this topic will be invoked with the event data. Parameters:
  • topic - The topic name to publish to
  • pubsub_data - JSON value containing the event data
Note: This method does not return an error. Implementations should handle errors internally with logging.

subscribe

Subscribes a function to receive events from a topic. Parameters:
  • topic - The topic name to subscribe to
  • id - Unique subscription identifier
  • function_id - The function to invoke when events are published
Behavior:
  • When an event is published to the topic, the specified function is called with the event data
  • Multiple subscriptions to the same topic are supported
  • Subscriptions persist until explicitly unsubscribed

unsubscribe

Removes a subscription from a topic. Parameters:
  • topic - The topic name to unsubscribe from
  • id - The subscription identifier to remove
Behavior:
  • Stops the function from receiving events for this topic
  • If this is the last subscription, resources may be cleaned up

Available Adapters

RedisAdapter

Redis-based pub/sub for distributed event messaging across multiple engine instances.
Features:
  • Distributed messaging across engine instances
  • Persistent connections with automatic reconnection
  • Asynchronous event handling
  • Per-topic subscription tasks
Source: /workspace/source/src/modules/pubsub/adapters/redis_adapter.rs

LocalAdapter

In-memory pub/sub for single-instance deployments and development.
Features:
  • Zero external dependencies
  • Low latency event delivery
  • Perfect for development and testing
  • Events only delivered within the same process
Source: /workspace/source/src/modules/pubsub/adapters/local_adapter.rs

Example Implementation

Usage Example

Defining a function that subscribes to events:
Publishing events from another function:

Implementation Notes

Error Handling

The publish method doesn’t return errors. Implementations should:
  • Log errors internally using tracing::error!
  • Continue processing other subscribers if one fails
  • Not block the publisher on delivery failures

Concurrency

Subscriber functions are typically invoked concurrently:
  • Use tokio::spawn to invoke functions asynchronously
  • Multiple events can be processed simultaneously
  • Consider rate limiting for high-volume topics

Cleanup

Implementations should:
  • Track active subscriptions and spawned tasks
  • Abort tasks when unsubscribing
  • Clean up resources when topics have no subscribers
  • Implement proper shutdown on adapter destruction