GA4GH Web components are the reusable custom elements that can be utilized in your web apps & web pages independently irrespective of what framework/library you are using to build the frontend.
Is your feature request related to a problem? Please describe.
The GA4GH Tool Registry Service (TRS) API specification allows accessing computational analysis workflows of various languages (in principle any language, but currently explicitly supported are CWL, Galaxy, Nextflow, Snakemake & WDL) as well as resolve container images for individual tools.
TRS-Filer is a lightweight implementation of TRS that is not bound to any particular data source. Apart from the endpoints defined by TRS, it also specifies corresponding POST, PUT and DELETE endpoints, so that it can be used to register workflows and tools. As such, it can be used (1) as a TRS-compatible shim around an existing workflow or tool repository, and (2) as a backend for storing available workflows/tools inside a web portal operationalizing GA4GH Cloud APIs, such as Krini.
Describe the solution you'd like
Implement a Web Component client for TRS-Filer that serves both of the above-mentioned use cases. Note that this may require the use/packaging of multiple reusable child components or the reuse of already exisiting ones. Before starting the implementation, please draft a brief design proposal. Note that the component should also work with any spec-compliant TRS implementation - that is, functionalities only available in TRS-Filer should be optional. Note also that workflow descriptor data can be stored right inside the TRS-Filer database. However, the same may not be true for all data in a TRS resource, e.g., test files or container images. Think about how to integrate with #33, #34 and how to store container images (ideally find an OCI-compliant, self-deployable, free and open source container registry) that we could write another component for, analogous to the MinIO object store as described in #34.
Is your feature request related to a problem? Please describe.
The GA4GH Tool Registry Service (TRS) API specification allows accessing computational analysis workflows of various languages (in principle any language, but currently explicitly supported are CWL, Galaxy, Nextflow, Snakemake & WDL) as well as resolve container images for individual tools.
TRS-Filer is a lightweight implementation of TRS that is not bound to any particular data source. Apart from the endpoints defined by TRS, it also specifies corresponding
POST,PUTandDELETEendpoints, so that it can be used to register workflows and tools. As such, it can be used (1) as a TRS-compatible shim around an existing workflow or tool repository, and (2) as a backend for storing available workflows/tools inside a web portal operationalizing GA4GH Cloud APIs, such as Krini.Describe the solution you'd like
Implement a Web Component client for TRS-Filer that serves both of the above-mentioned use cases. Note that this may require the use/packaging of multiple reusable child components or the reuse of already exisiting ones. Before starting the implementation, please draft a brief design proposal. Note that the component should also work with any spec-compliant TRS implementation - that is, functionalities only available in TRS-Filer should be optional. Note also that workflow descriptor data can be stored right inside the TRS-Filer database. However, the same may not be true for all data in a TRS resource, e.g., test files or container images. Think about how to integrate with #33, #34 and how to store container images (ideally find an OCI-compliant, self-deployable, free and open source container registry) that we could write another component for, analogous to the MinIO object store as described in #34.