[FOLIO-971] How does an administrator add new apps to the App Store? Created: 06/Dec/17  Updated: 18/Jan/19

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Nassib Nassar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: devmtg-201801
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Sprint:
Development Team: Core: Platform

 Description   

How does an administrator add new apps to the App Store? By specifying URLs that point to GitHub repositories? What do the UX and back-end look like for this? Later there will have to be a distribution system of some kind to make this process less manual; are there any implications of that for the current design?



 Comments   
Comment by John Malconian [ 08/Dec/17 ]

An "app store" pointing to source code repositories seems a little odd. Why not to actual application artifacts? Perhaps a distribution model not so dissimilar to linux-based repositories. For example, an "official" core FOLIO application repository ("core/base") and a user/community-contributed repository (user-contrib) as well as the ability to add third-party or private repositories similar in concept to adding third-party yum or apt repositories. Also, additional possibilities of separate
"stable" vs "experimental" repositories, etc.

Comment by Nassib Nassar [ 08/Dec/17 ]

I wasn't very clear. So I'm assuming that a distribution model might not be ready for the first "release" of the app store, but maybe that is not a fair assumption.

If there is initially no distribution model, I imagine the app store needs some way to add new apps individually, and my first thought was that GitHub URLs might be easy for users to understand and enter/feed into an app store configuration. Maybe there could be a metadata artifact that describes the app, in a well known location in each repository that the app store can find.

In terms of a distribution model, I had in mind exactly the same linux-style model that you describe.

Comment by Jakub Skoczen [ 08/Dec/17 ]

Nassib Nassar I think a starting point for this analysis is the current model we have in place for:

  • Central Registry (http://folio-registry.aws.indexdata.com) – centralized FOLIO package metadata and dependency registry, integrated with FOLIO CI. CR deployment descriptors point to dist artifacts (maven/npm/docker)
  • FOLIO snapshots (http://folio-snapshot.aws.indexdata.com) – FOLIO vagrant distribution and AWS deployment constructed for daily snapshots of pre-selected Apps, with dependency resolution provided by CR

Those systems are the most basic building blocks for FOLIO App Store. What's missing is:

  • a mechanism for dynamic selection of Apps – here the main element is a module, along the lines of (now deprecated) 'okapi-stripes', which allows dynamic generation of FOLIO Stripes bundle, based on the admin's selection of Apps. Relevant here is the current work from Matt Jones on 'stripes-cli', which will serve as the foundation for said module.
  • App Store UI – (possibly a FOLIO App) a graphical interface to the above module and selected Okapi tenant services
Comment by Jason Skomorowski [ 08/Dec/17 ]

As for adding new Stripes apps, you include them in a new version of your 'platform' which is little more than a list of available apps presented as an npm package to readily facilitate pulling in the necessary dependencies. NB, per-tenant configuration does not specify versions of apps, the platform does. The tenant config chooses a subset of the platform to enable. This narrows the possible combinations of versions to the available platforms so we don't wind up in a situation where every deployment is unique. A unique combination can be offered to a tenant that needs it via a custom platform but that would be an explicit choice.

Generated at Thu Feb 08 23:09:52 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.