Apps / Plug-in Architecture

[jjgao]

Currently, contributions to the cBioPortal code base are tightly controlled through pull requests to the main codebase. To allow more distributed development and contributions from the community, we may want to consider migrating to a plug-in/apps architecture, which will allow:

• others to write apps to the main software;
• apps to be maintained by plug-in developers/owners (which will remove the burden of reviewing and maintaining in the main codebase).

Technical challenges / discussion:

• How to evolve the current architecture to support apps?
• Is it possible to have an apps architecture to support both frontend and backend?
• How to ensure the quality of an app?
• Frontend (JS) and backend (Jave) API

Example software tools that support apps/plug-ins:

• Jenkins plugins
• Cytoscape and its app store
• Google Drive Add-ons / Apps Script

@cBioPortal/frontend @cBioPortal/backend

[Luke-Sikina]

Some unorganized thoughts:

• Preventing collisions between plugins seems like a challenge (routes, apis)
• I have no idea how we go from that jitpack artifact for the frontend to a modular system. I'm guessing more of the frontend gets built during backend compilation?
• Code quality doesn't actually sound like a big issue to me. I think most people would only risk getting a plugin from a trusted source, so as long as you can verify who wrote the plugin, it should be fine.
• How does a plugin that consists of a backend component and a frontend component work? Do you just provide a jar and js blob? This is probably pretty straightforward, but the core idea of a plugin being two distinct components is breaking my brain a little bit.
• How do proprietary plugins work? Is there a way to reference a plugin built locally and not sourced from the store?
• How does the study view filter handle all this? If two different plugins want to make additions to the study view filter, how does it not explode?

Some unorganized but more positive thoughts:

• This seems like a great way to allow for a more customizable portal. Given how different portals have grown to have different data and performance needs, this seems awesome.
• This would be a good opportunity to break up some of our more massively monolithic portions of the application (6,000 line store files come to mind)