Merge pull request meshery#13066 from Deeptanshu-sankhwar/docs/clarif…

…y-event-persistence [Docs] Updates the documentation to clarify event persistence behaviors (Issue meshery#13058)
steve-aldrin · Jan 1, 2025 · cf598cc · cf598cc
2 parents 65db39c + fdd247c
commit cf598cc
Show file tree

Hide file tree

Showing 2 changed files with 21 additions and 0 deletions.
diff --git a/docs/pages/extensibility/providers.md b/docs/pages/extensibility/providers.md
@@ -48,6 +48,15 @@ There are two types of providers defined in Meshery, `local` and `remote`.
 
 The use of a Remote Provider, puts Meshery into multi-user mode and requires user authentication. This provides security for the public-facing Meshery UI as the remote provider enforces identity with authentication and authorization. You should also use a remote provider when your use of Meshery is ongoing or used in a team environment (used by multiple people). This can be seen when using Meshery Playground, where a user is prompted to login through the _Layer5 Meshery Cloud_ remote provider. Visit [Meshery Playground](https://playground.meshery.io/) to experience this.
 
+#### Event Visibility in Remote Providers
+
+Meshery's extensibility framework for remote providers currently does not include automatic propagation of events persisted locally by `provider.PersistEvent(event)`. To address this limitation, remote providers could be enhanced to optionally subscribe to and process server events. This would involve:
+
+- **Provider-Specific Event Handling**: Allowing remote providers to define the types of events they wish to consume, ensuring tailored integration for different provider use cases.
+- **Event Subscription APIs**: Introducing APIs that enable remote providers to subscribe to server events dynamically, improving their ability to offer real-time insights and actions based on event data.
+
+These enhancements would strengthen the integration between Meshery and its remote providers, making the platform more adaptable to varied deployment needs.
+
 A specific remote provider can be enforced in a Meshery instance by passing the name of the provider with the env variable `PROVIDER`.  
 
 Name: **"Meshery"** (default)

diff --git a/docs/pages/project/contributing/contributing-sever-events.md b/docs/pages/project/contributing/contributing-sever-events.md
@@ -119,6 +119,18 @@ Meshery has two primary clients: Mesheryctl and Meshery UI. Both clients will pr
 
 Clients can send HTTP POST requests to [`api/events`](https://docs.meshery.io/reference/rest-apis#api-events) with the event encapsulated in a JSON request body. Upon receiving an event, the server processes, validates, and broadcasts it using the Broadcaster. This ensures that all relevant events generated by Mesheryctl and Meshery UI are effectively communicated and managed by the Meshery Server.
 
+### Event Persistence and Remote Providers
+
+Currently, the `provider.PersistEvent(event)` function is designed to persist events within the Meshery Server's local storage. These events are not automatically sent to remote providers, which means that remote providers do not have access to these events unless explicitly shared.
+
+**Is more control needed?**  
+In environments utilizing remote providers, it might be beneficial to introduce additional control mechanisms to selectively propagate events to remote providers. This could involve:
+
+- **Selective Event Propagation**: Allowing configuration to specify which events should be sent to remote providers.
+- **Enhanced Interfaces**: Developing interfaces to enable Meshery Server to transmit specific events to designated remote providers as required.
+
+Implementing such mechanisms can enhance observability and coordination across local and remote providers, ensuring that events are effectively disseminated and managed.
+
 ### Example 
 
 ```javascript