Skip to content
This repository has been archived by the owner on Jun 1, 2023. It is now read-only.

standard way to describe the solutions in a registry #168

Open
sameh-farouk opened this issue May 31, 2023 · 0 comments
Open

standard way to describe the solutions in a registry #168

sameh-farouk opened this issue May 31, 2023 · 0 comments
Labels
type_feature New feature or request

Comments

@sameh-farouk
Copy link

Description

I have an idea.. imagine we don't need to have separated source files to show the different weblets. instead, we have a solution registry (just another github repo) that host a list of known solutions typically used on the grid in a JSON data file.

a Solution along side all required fields, description, envs, and flavors specs can be derived and rendered on the fly from the JSON data file in this repository which contains entries to describe the solutions in some standard way.

More Details

note: this is just an quick example, it could be better crafted with more planning.

{
	"networks": ["dev", "qa", "test", "main"],                // networks which the solution would shows
	"displayName": "peertube", 
        "description": "Peertube aspires to be a decentralized and free/libre alternative to video broadcasting services.",
        "helpUrl": "https://manual.grid.tf/weblets/weblets_peertube.html",   
	"flist": "flist-url",              
	"flavours": [{"standard": {"cpu": , "memory": , "disk": }}],                  
	"envs": [{"envName": "ADMINEMAIL", "fieldName": "Email", "Description": "", "Validators": ["emailAddresss", ] 
         ],     
	"adminPanelUlr": "https://astar.network",
},

now, the flow for development of a new solution weblet would be just:

  • Clone the registry repo
  • Add an additional solution data to the json file
  • Commit, push and then open a pull request.
    Once it get accepted and merged, the new weblet would show up in the playground on the mentioned networks without any modification to the playground source code, as it always request this json file and parse it on load. it would show up in any app/tool that sync and render our solutions data from that repository/registry.

If new solutions needed to be always tide to a release, the playground could be synced with a specific registry-commit, or tag.

If someone come up with a mobile or desktop application, he would also sync the solutions from that repo/JSON file, and render its UI based on it without also any modifications when new solution introduced, which could greatly simplify the development of a new solutions and maintain existent DAPPS.

This would perfectly work on apps that not required special handling from UI. for apps that need special handling, these would be included as well in the registry but to provide the extra/special handling, further modification to client code could be needed, as usual. example would be K8s and Caprover deployment, but this would be a rare case.

More

please let me know your opinions.

@sameh-farouk sameh-farouk added the type_feature New feature or request label May 31, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type_feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant