Connect GitHub API to QualOpt

[softeng-701]

Currently, the site has only used mock participant data or no data at all for its database. The site needs to be connected to the GitHub API so that actual GitHub users' emails can be acquired for use in surveys.

NOTE, REALLY IMPORTANT: You must ensure that no emails are sent to actual GitHub users during this project. Make sure that either any emails are sent to fake addresses or that no emails are sent at all.

[dylHall]

Will begin investigating this feature request - this is related to Issue #39, so will work alongside Kalana (Group 5 - Auka).

[dylHall]

After Chamara and I worked on this and had a discussion with Kelly and Latha, I just wanted to write down the high-level workflow that we’ve currently planned for in our implementations of features in #39 and this issue.

Initially, a Researcher will use the tool to establish their Studies in the web app and will check the participants currently present in the database to send email invitations/information to them. If the Researcher doesn’t have access to enough Participants, then can move to the Participants page and press the new “Send GitHub API Query”…

…to bring up a form to fill out that will allow them to send a custom user search to the GitHub API

This request will be converted to the appropriate API Call to GitHub, and will take the JSON representations of resulting users returned from GitHub into Participants.

This allows the Researchers to have the “initiative” in a sense – they can find the GitHub users they want and then send out emails to them. However, if a GitHub user receives an email and wishes to opt out (#39), then they should be able to log into the service and be taken to a new page to configure the studies they want to receive emails about. Please refer to #39 for some further discussion about our current plan for the logging in and management of users after receiving these emails.

The GitHub API Request is routed from the model backing the front end form, to a resource handler in the backend server – this is because Angular 4.2.6 doesn’t have access to HttpClient and other higher-level connection objects. As a result, I encountered many CORS issues when trying to send a query to the GitHub API. To promote interoperability between different browsers and configurations, I thus developed a backend solution to send this API request (using a GitHub API Maven repository to provide domain objects to the solution). Having this domain model present should help #41 add extra information to Participants, as any information can be acquired for “free” in a sense (just add GHUser#Get…. calls).

Here are a few of my suggested improvements based off of the work started here: (@kblincoe, @softeng-701, are there any of these features that you’d like me to spec and add to the issue list?)

• I didn’t add much of a feedback representation for having these Participants added, they will simply all appear on the table after the request has concluded. We could try to implement a loading animation or representation to show that a GitHub search is currently occurring.

• To obtain the Contribution Counts of users is an extremely network intensive process currently – it requires an almost cartesian explosion in network requests due to separation of information in the GitHub API, and the REST nature of the querying (You have to get ALL of the users repositories, and for each repository, find that individual user as a contributor). Having some GraphQL query/some wrapper solution could alleviate the inefficiency of making so many network calls.

• Adding a dedicated GitHub key to this application to increase the allotted API Calls that can be made per hour. Currently, I opted to make an anonymous connection with the API, which means only 60 API calls can be made per hour. Providing an authenticated connection will increase the allotted API calls to 5000 per hour.

• We could increase robustness to network failures by adding timeouts to the backend resource handlers – this would likely be a Springboot configuration applied across all the resource handlers.

• Change the implementation to use the real GitHub user emails instead of fake email addressed produced. This would be a single line change but should occur after all the testing with emails has concluded.

If you’d like any information about the implementation, please refer to the Pull Request for this branch or reach out to me for any specific questions!