# GSoC Proposal for Fitbit Web API Subscription and Nutrition API Extension
## 1.Personal Background
- Contributor full name: Junjie Zhou
- Email: [e-mail]
- Link to profile: https://github.com/jzhou59

## 2.Relevant Skills and Interest
### 2.1 Educational Background
- M.Sc | Southeast University | Computer Science | 2019 - 2022
- I am pursing my master degree in Southeast University, researching in privacy protection.
- B.Sc | Changshu Institute of Technology | Internet of Things | 2014 - 2018
- I got my bachelor degree from CIT where I started getting to know computer and programming.

### 2.2 Relevant Experience
- SDE @ Honor Terminal Co., Ltd. | Aug 2021 - Oct 2021
- I worked as a software development engineer intern here. I was in responsible for 1)Java development based on micro-services framework, 2)Middle ware integration such as Kafka, Redis, and MongoDB etc.

### 2.3 Prior Open Source Contribution
- Apache/incubator-eventmesh | Jul 2021 - Now
- Responsibilities:
- Survey the integration of schema registry in other middlewares, such as EMQ/Pulsar/Kafka.
- Design architecture of integrating OpenSchema into Eventmesh.
- Implement a standalone service as OpenSchema server.
- Implement integration of OpenSchema in the form of SPI plugin.

### 2.4 Link to Code Sample in The Related Technology or Area
- My Public Repo
- https://github.com/jzhou59?tab=repositories
- I am contributing on several public repositories, most of which are Java-related.

## 3 Project Proposal
The RADAR-REST-Connector contains a Kafka Connect source connector for a general REST API, and one for Fitbit in particular. This allows for pulling the wearable data from Fitbit servers using their Web API.
### 3.1 Project Goal
There are following three general goals I am going to accomplish at least:
- Update current Web API(heart-rate-related and sleep related) requests.
- Add another Web API(nutrition) request for Kafka.
- Integrate a Fitbit subscription API to RADAR-REST-Connector so that it can retrieve data when necessary.

### 3.2 Requirement Analysis
Requirements for three goals are analyzed separately:
- First, for current connector, there might be lacking of collecting some data inside some web requests since those data were added lately by Fitbit. However, those data should be collected aiming at providing a more comprehensive platform. So such API should be modified to catch up Fitbit's updating. (Relating to issue https://github.com/RADAR-base/RADAR-REST-Connector/issues/89)
- Second, for the newly added Fitbit service, Kafka-connector has not supported that, especially the nutrition service of Fitbit. Therefore, a new request, along with the parsing of response data, should be added into Kafka-connector so that the source connector could retrieve the nutrition-related data.(Relating to issue https://github.com/RADAR-base/RADAR-REST-Connector/issues/91)
- Third, currently, the implementation of Kafka-connector is PULL-based, namely it makes requests chronologically without any knowledge of presence of data on Fitbit's servers. This however is very passive in interaction with Fitbit. So there is a need for implementing the Fitbit Subscriptions API (a PUSH based mechanism). In this case, the Fitbit API will send a notification informing there is new data available. On receiving this notification, Kakfa-connector can make request for the specific data provided in the notification hence mitigating the issue stated above.(Relating to issue https://github.com/RADAR-base/RADAR-REST-Connector/issues/88)

### 3.3 Project Plan
I will introduce the project plan from two aspects: my current understanding of the project code and things I have done until now.

#### 3.3.1 Understanding about project
In general, ```RADAR-REST-Connector``` is a project for collecting data from upstream data providers, such as the Fitbit which have been currently supported. Without running as a separated server, it utilizes the most of ```Kafka Connect``` through creating SourceConnectors to pull data from third-party servers.

To be specific, two modules are currently in the project: ```kafka-connect-rest-source``` and ```kafka-connect-fitbit-source```. The module ```kafka-connect-rest-source``` could be viewed as a general module that defines the abstract interfaces when collecting data from third-parties server. The module ```kafka-connect-fitbit-source``` could be viewed as one specific implementation of the general module. When later comes another third-party data providers, creating a new module is good to go.

In the following development, updating existed api and adding new api are mainly coding inside the ```kafka-connect-fitbit-source```, and integrating subscription may need re-organizing codes insides both ```kafka-connect-rest-source``` and ```kafka-connect-fitbit-source```.

#### 3.3.2 Things have done

For updating current API: schema and logic code shoule be modified. And **I have updated such logic code with newly generated schema classes, together with some other configurations and route logic**(https://github.com/RADAR-base/RADAR-REST-Connector/pull/92).

For adding Nutrition's API, I have surveyed the official documentation and arraged the procudure to develop it which is reflected in below timeline.

For Fitbit subscription integrating, I have checked the official documentation and knew how it is working. The newly data flow after integrating subscription in Kafka-connector is just like the following figure.

### 3.4 Availability
- Expected working hours on GSoC 2022: 350-hour(full hour), UTC +08:00, 5hrs/workday night
- Other commitments: 1)may spare time for dissertation, 2)may work late. These two commitments may take up the time. However, it will not be common and if some day is taken up I will extend the time on this project the next day.

### 3.6 Reason for the choice
I would like to split the reason for the choice into two parts: RADAR-base and the project.

As I can know from the RADAR-base official website, the mission which is to improve people’s quality of life by leveraging clinical value from wearable sensor data and smartphones inspires me to contribute to it. Many people have been suffering from different kinds of health issues and I believe RADAR-base is trying it best to help such issues to be addressed.

And I choose the kafka connect related project from the idea list mainly in three reasons. First, I am interested in cloud native and backend development so I am willing to contribute myself into it. Second, I have the background of relevant development which enpowers me of the ability to accomplish it well. Third, the project needs continuously updation as long as upstream providers update the protocol and I would like to contribute to it in the long term.

### 3.5 Timeline
Below it the timeline.
| Period | Activity |
| --- | --- |
| May 20 - June 12 | Community Bonding Period: Meeting mentors and discuss the specific implementation plan.|
| code actually begins | |
| 1st week(June 13 - June 19) | This week, I will focus on implementing the code of updating existed APIs.|
|2nd week(June 20 - June 26) | This week, I will focus on writing the unit test of updated API based on JUnit.|
|3rd week(June 27 - July 3) |This week, I will focus on documenting the API related functions/protocols in the README(or other place such as wiki page).|
|4th week(July 4 - July 10) | This week, I will focus on designing nutrition-related requests, mainly about calssifying related requests(nutrition has many api in its official websites) and designing the route policy for each classification.|
|5th week(July 11 - July 17) | This week, I will focus on implementing the code of nutrition-related requests API.|
|6th week(July 18 - July 24)| This week, I will focus on writing the unit test of newly added content based on JUnit.|
|7th week(July 25 - July 31) | This week, I will focus on submitting phase 1 evaluation of GSoC.|
|8th week(August 1 - August 7) | This week, I will focus on documenting the nutrition-related functions/protocols inside the README(or other place such as wiki page).|
|9th week(August 8 - August 14) | This week, I will focus on designing the way of implementing Fitbit subscription integration.|
|10th week(August 15 - August 21) | This week, I will focus on implementing the project code of subscription integration.|
|11th week(August 22 - August 28) | This week, I will focus on writing the unit test of subscription-related codes.|
|12th week(August 29 - September 4) | This week, I will focus on documenting how the subscription is working in the README(or other place such as wiki page).|
|13th week(September 5 - September 11)| This week, I will focus on submitting phase 2 evaluation of GSoC.|