drio / segmenthunter Goto Github PK

In this milestone we want to stabilize the code to make changes easier.

1. All the components have to deal with presentation.
   • extract away the pieces of logic and moving it outside the component.
   • maybe create a storybook for the components
2. The logic to get data is convoluted
   • refactor all the data loading and connect and expose it properly to the components.
     Probably we want to use a data store (in rxjs).
3. Write tests
   • for all the components (maybe storybook is enough).

From #1

• add help (home page?) to show people how to use the app
• Incorporate wind speed in scoring algorithm
• Increase the time for which the strava token is valid. Check when it has expired and rerun oauth
• Add contact page
• write tests for the different algorithm score cases
• Improve time axis on slider so we show date details (like in windy)

I have already code to load the strava data.
The logic for that is a simple promise that makes the API requests and returns a list of segment details.

When we load the app, we want to check the storage and if data is there and is new enough (24h strava, 1h weather) we load that data. If not, we make requests to update.

At the moment, we are going to go over that process when we load the app.

API:

dataLoader.load().then(d => doWork(d));

Next milestone in #5

High priority

• add help (home page?) to show people how to use the app
• fix location issues: if we cannot get the location, we can look into the segments coordinates.
• Incorporate wind speed in scoring algorithm
• Increase the time for which the strava token is valid. Check when it has expired and rerun oauth
• update icon in strava app config page
• refactor UI to add login/logout
• refine oauth process
• #2 Implement OAUTH in client
• #3 load data (strava/weather) and store in local storage
• Get current location when pulling weather data
• Use current location to determine map centering and zoom
• The weather gov API is not reliable; explore alternatives and prepare in case things fail
• #4 Write production pipeline decided to go to vercel
• Refactor segment logic so the Map component receives only a segments property and we do the local vs global in a dedicated file.
• Fix bug in Map where we don't associate score colors on load (see fixme entry).
• Get domain
• Add contact page
• Write production pipeline
• make the loading page pretty
• write tests for the different algorithm score cases

Others

• Incorporate profile image and username in UI
• Allow hiding controls
• Improve time axis on slider so we show date details (like in windy)

main 🎫

Decided to deploy to vercel.
AWS's instances crash when you are building the app since they are using too many resources. Not sure if this is because I was using a free tier but I cannot spend more time on this right now. I want to launch.

The production env is a ubuntu box.

We need:

• configure nginx to process the new domain.

1. Point the domain to the server ip
2. update nginx config
3. test.

• modify nginx config to redirect to the app (port 3000).
• write a systemd script to load the app on reboot
• add a few metrics to monitor usage

Always up

How do we ensure the app is always up in between deployments? Here is what we can do.

We have two versions of the app running. Nginx redirects traffic to one of the apps. On deployment,
we pick the instance that nginx does not use, build the code and restart the server. Then we update the nginx
config to redirect to the other instance.

So we have to:

1. detect what instance we are not using.
2. rsync latest master to the instance
3. build and restart
4. update nginx and restarat

All tickets: #1

Todo

• / write index page and check for strava token.
  Is there? carry on with the app.
  Not there, redirect user to http://www.strava.com/oauth/authorize
• /exchange_token.
  Make request to strava api to get token.
  Store token in session.
  Redirect to index OR error page.
• /ups
• /signout deletes the cookie.

Details

The protocol is something like this.

The user lands in app.

Do we have a strava token in the session? YES: load the app.
NO: We have to redirect the user to:

http://www.strava.com/oauth/authorize?
client_id=$CLIENT_ID
&response_type=code
&redirect_uri=http://localhost/exchange_token
&approval_prompt=force
&scope=read

In production, we will use whateverdomain.com instead of localhost.
NOTE: to test your app when you have already launched, you probably want to modify /etc/hosts in your OS to point whateverdomain.com to localhost. Is there any alternative?

Now, the user clicks ok. So strava makes a request to our server (localhost/exchange_token) sending the code in the params. Before sending the page to the user, we make a request to strava (from our server) to get the authorization
token (access_token in the payload). We probably want to check other things like the type of access we have to the API.
If all is good, we save the token in the user session so we can use it client side to make requests. Then we redirect the user
to load the app.

Routes

/exchange_token
/index (the app)