Component Registration

[ForbesLindesay]

I've been looking at trying to improve the "self registration process". I have two thoughts on how we can improve this:

1. Don't use self registration for core components - it makes perfect sense for plugins where they can access the glimpse API to register themselves, but very little sense for core components where they are explicitly loaded from somewhere. Wherever possible, a module should provide an external API and loading it should be side effect free. By having calling code explicitly register the components, we can achieve this.
2. We seem to have one more level of indirection than we're actually using. We have applications self registering into the shell and "tabs" self registering into the "request". The second of these makes perfect sense, but I'm not sure I can see a strong use case for plugins registering additional applications into the shell?
3. It seems to me like request/request.js (which is responsible for telling the repositories to fetch data) is really just a dependency of request-user-view.jsx and request-summary-view.jsx. We could move the relevant code to there and remove that awkward self-registration.

These changes should also make it easier to test components in isolation.

[avanderhoorn]

@ForbesLindesay I've never been happy with the "self registration" process, but never had time to get around to fixing it.

Current extensions points

• Sub Application: This is the terms we are currently using to allow the over all system to pivot on the data we have in very different ways.
  • Currently the only Sub Application we have is the Request one. In time we will be adding other - Exception (which shows an exception focused view of the world), Trace/Log (which shows all logs across all requests regardless of request), Environment/Configuration (which shows the current servers at play, the config setup, requests flowing through, etc, etc), etc
  • The UIs for each of these will be specifically designed to fulfil the task at had. For example, the current Request Sub Application is all about how to view, filter, conceptualise incoming requests.
• Request Tabs: These are an extensions which (for the moment) are specific to the Request Sub Application. It allows us to take the same request data payloads (usually.... but keep in mind a tab could request additional resources/data from the server) and showing the data in different ways depending on how the users wants to visualise requests.

Self registration for core components

You brought up the point about why should happen and in the end it comes down to wanting to make sure we treat all components/extensions the same - whether they be ours or ones the community writes. We have run into trouble in the past when we don't dog food our own external APIs enough and people couldn't achieve the same style of extensions or results as we have. This time around we really want to treat anything that is "Core" as the base platform, any everything that plugs into that as extensions (whether it is ours or someone else's). At its extreme, imagine that eventual, the Request Sub Application could even be shifted to its own Repo and at the very extreme, the Request Sub Application's various tabs could each be in their own Repo.

Any of the above isn't to say that we can't do it better, so don't be put off. This is just some of the reasoning and logic behind why we are doing what we are doing.

[ForbesLindesay]

It sounds like the best bet is probably to try and push this a bit further towards it's logical conclusion, by separating things out, into core components, and each conceptual plugin. This should help them serve as useful examples of what a plugin should look like.

With that goal in mind, how are plugins going to be distributed, and how do they have their JavaScript injected into the application? Are they appended as separate "script" tags with access to certain globals, or do they get require'd in via web-pack?

[avanderhoorn]

Yep thought you might ask that ;) Haven't got that covered yet... still been trying to think of the best approach.

Inclusion on users site:
Couple of different options might work, but nothing that hits the nail completely on the head yet:

• Middleware: That intercepts the call for the client code, looks to see what glimpse client plugins are in place and merges them into the one payload and serves them up. Determining client plugins could be done by convention or either in name or placement, etc.
• Build Task: Similar to the above except that this happens at build time using the same conventions above.

What I would like to avoid is the user of the site needing to add multiple scripts of to the page just to get the base Glimpse experience.

Relationship between server and client plugins
We haven't quite yet worked through the relationship yet. For the most part, to run correctly, Client side plugins need specific data from the server and the server will only provide this data when the relevant server plugin exposes it.

For example, the Request Sub Application is going to be a client side plugin that requires data from the Request Sub Application on the server. Then each of the tabs that we currently have speced for the client side Request Sub Application should run just fine from the data provided by the server Request Sub Application.

Traditionally, client and server plugins have been bundled to help make this easier for users, but with what we are wanting to do here, things might get a little harder to understand/get right for our users. Getting this usability right is our top priority, hence even though we might design the components to work independently, we might bundle what we classify as the "default" experience in one package... not sure yet.

[avanderhoorn]

Ok, going over this I think we might have come up with some answers that might work.

Client must work without the server:
An over arching principle for the client is that it needs to be able to function without the server being present. This goes for initial startup to if we loose socket connections to the server. What experience they will have if they just start the client without the server in place, probably wont be much, but this is a base to start from.

Loading of client plugins:
As discussed in the above, how client scripts get into the page is up for discussion. Currently, the best thought is that the server will send down metadata which the client will read. From this metadata, the client be able to determine which modules are needed (modules equating to hosted files) and load those asynchronously. Considering that we want the client to work without the server (meaning metadata mightn't be present) other options may be to include a list of modules to be loaded in the main script tag or the user to simply include the script tags manually. Unless otherwise needed, async module loading will be done via the selected packers (webpack) built in functionality.

Synchronising client packages with their server counterparts:
The client core should provide a base service which allows a plugin to define which server resources (plugins/extensions) it needs in order to operate. This service will lookup the metadata provided by the service which has the list of available server resources. If resources are missing, depending on whether the resource is "required/needed" or "optional/enhancing", the service will hold the plugin from loading and notify the user why, or load the plugin and warn them that x resource is missing. Ideally the definition that the client plugin has for resources also defines why it needs the resource - allowing messages delivered to the user to be richer in nature.

Hopefully this helps move forward for the moment. Once the architecture solidifies more we will break the repository up. In preparation for this, if we want to pull the request sub application into a higher level folder, thats fine with me, but its not a top priority, lets work through the rest of the list first.