Ideas on plugins and config APIs - GluuFederation/gluu-admin-ui GitHub Wiki

Hi readers,

As I've mentioned in the past, we are expecting to add plugins to gluu-admin-ui for casa and passport administration purposes

We also have https://github.com/JanssenProject/jans-config-api/issues/29

Mike wants casa-config, passport-config, and other potential apis to reside in jans-config-api project, not as separate components. That's the reason the issue was open

So, recently I have been studying the 3 repos involved: jans-config-api, gluu-admin-ui, and gluu-admin-ui-api trying to understand what's required to make this work

I am not liking much that:

  • It requires coding at 3 different places, and given that every repo is built around different frameworks it is demanding in term of skills. This makes development or customization by 3rd parties (partners/community) not very friendly. It sounds like we would have to document a lot of things

  • Unless I am not understanding the front-end architecture correctly, the "plugability" offered by it is questionable: plugins are located under the same codebase of gluu-admin-ui. It's like we need to have all known plugins developed a priori and then, use the backend as a workaround to know which ones are hidden/shown. It's more like feature toggling

    Ideally a plugin should be added as a separate artifact as the backend currently does. In this case I imagine something like adding a node_module to the project. This favors modularity and isolation.

I don't have expertise in javascript platform as to suggest something, but I remember that when the project started I heard someone talking about that plugins could be provided as external artifacts (in a URL) or something... This seems a more realistic use case where partners can distribute plugins for customers. Also, we don't have to host in our repository plugins which are intended for specific companies

So far I have the following suggestions:

  1. Can the front-end on its own maintain the list of plugins to show? Thus, we can save development of dummy jar files in the backend. One layer less to worry about...
  2. Rarely new Gluu components are added to Gluu. I think that we can maintain jans-config-api plugin-free (jans-config-api#29). We'd just add Casa and passport config APIs the usual way (and disabling endpoints by inspecting the environment, eg. passport is not installed). This will also save us time doing R&D on how to add REST services and code on the fly in a quarkus app
  3. Evolve gluu-admin-api to support a more realistic plugin approach as I pointed out previously. The health check plugin is extremely simple and since it worked, maybe it drove us to conclude we were fine with plugins support. Let's think about a more elaborated scenario.

With these 3 points above we can focus on plugins in a single place, unique platform (JS).