[discuss] Introduce render data provider API

[joshdover]

In the legacy platform, we have the concept of "injected vars" which allow plugins to provide functions on the server that return values to be exposed to client-side code.

Some problems with the legacy implementation of this:

• The server blocks on rendering the bootstrap HTML & JS on executing this functions (which may be async). This delays the loading of the frontend code for data that may not be necessary to start using the UI.
• Some injected vars are shared across plugins. Any plugin can access any other plugin's injected vars creating implicit dependencies between plugins which can easily cause breaks if a plugin is disabled.

In the Kibana Platform, we introduced the exposeToBrowser config option to expose config values to the frontend. This covers most cases that injected vars was being used for, however there are some use cases that cannot be solved by this:

• The short URL plugin uses an injected var to provide the frontend with the resolved URL fetched from a Saved Object. Without injected vars, the service requires loading this data via an async request to a separate endpoint after the frontend has loaded and started. [Dasbhoard][Short URL] Parse embeded in the short URL #54403 (comment)
• Security/spaces need to be able to detect if secure cookies is enabled based on the fact whether or not TLS is enabled, and spaces is enabled.

Drawbacks with requiring these plugins to get this data via a fetch to a dedicated endpoint:

• The request doesn't get started until after all JS bundles have loaded and core has executed the plugin.
• If enough plugins need this, we may have many requests that happen as soon as plugins are setup/started. These requests may get queued due to open connection limitations imposed by browsers.

Possible Solution

We could add an API to the RenderingService that allows plugins to register functions that provide data to the frontend, similar to the legacy platform, with some distinct differences:

• Plugins should only be able to read data that they provided themselves, not from other plugins. This should eliminate the issue where implicit dependencies between plugins can be created.
• These functions can be executed separate from the main render endpoint to avoid delaying the browser from starting to load and parse JS code. Instead, we can make a request to an endpoint in the bootstrap.js script so that this data can be loaded in parallel with JS and CSS. This endpoint would be provided by the RenderingService and would include return the data returned by all registered data providers.

class MyPluginServer {
  setup(core) {
    // Register a function to be executed by the RenderingService
    core.rendering.registerRenderData(async () => ({
      helloWorld: someAsyncFunc()
    }));
  }
}

class MyPluginPublic {
  constructor(initContext) {
    // Only data provided by this plugin's server-side code would be available
    this.helloWorld = initContext.renderData.helloWorld;
  }
}

Discussion

• Is this a premature optimization? Should we continue without the current pattern?

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Is this a duplicate of #52553?

[joshdover]

Ah yes, I'll move notes over to there and reopen.