The js_generic app is currently defined as a single endpoint as far as CCF is concerned. This is expedient, but comes with a number of limitations, in particular:

1. Since that endpoint is defined as Read/Write, to enable all use cases, all requests must be forwarded to the primary, leaving the followers unable to service read-only requests.
2. Although the /api does currently list js-defined endpoints through delegation, the effort to expose an OpenAPI schema will need to be duplicated.
3. Any change to a handler means the whole app must be re-submitted as a new proposal.
4. A Javascript-native single app container would almost inevitably expose a top-level scope, which is an undesirable pitfall (CCF's design mandates that the KV serves as the global scope).

Instead of building application runtimes as a single endpoint, we want instead the ability to dynamically register/de-register endpoints, which can be implemented in potentially different scripting languages, although CCF will ship with Javascript support for now. This registration should make use of the same API as the native C++ endpoints, and offer the same capabilities in terms of forwarding, authentication, api schema generation etc.