Currently, we have 2 Github fetch strategies from Github:
Default (pulling directly from Github through an unauthenticated HTTP request) and
App Server (making a request to the Appserver which will make an authenticated HTTP request to Github)
However, the current implementation is simple and not easily extensible. In order to have more structure and flexibility, we can:
Have a base class QuestionnaireFetchStrategy with abstract functions getRaw() or just get() and getContent() and any other you think will be useful. Then the concrete classes can be GithubQuestionnaireFetchStrategy and AppSeverQuestionnaireFetchStrategy. So if later we use app-config, you can just add a new class extending this strategy base class. Also, instead of GithubClient, it can be called QuestionnaireFetcher or something like that.
An alternative approach would be to make it specific based on protocol and definitions. So then you can change how each is pulled, then the base class QuestionnaireFetchStrategy can have abstract functions getDefinitions() and getProtocols(). But this will be a bigger refactor.
Currently, we have 2 Github fetch strategies from Github:
However, the current implementation is simple and not easily extensible. In order to have more structure and flexibility, we can:
Have a base class QuestionnaireFetchStrategy with abstract functions getRaw() or just get() and getContent() and any other you think will be useful. Then the concrete classes can be GithubQuestionnaireFetchStrategy and AppSeverQuestionnaireFetchStrategy. So if later we use app-config, you can just add a new class extending this strategy base class. Also, instead of GithubClient, it can be called QuestionnaireFetcher or something like that.
An alternative approach would be to make it specific based on protocol and definitions. So then you can change how each is pulled, then the base class QuestionnaireFetchStrategy can have abstract functions getDefinitions() and getProtocols(). But this will be a bigger refactor.