Slide 71
Slide 71 text
To scale this web-app, there will be a number factors to consider. They
are presented here in no particular order:
1) Traffic - How much traffic can my current server handle? The
technology stack was chosen for their ability to handle significant
traffic. The Apache server should also hold up as well, but AWS
might be a good alternative deployment option.
2) Connections to Strava - strava.com is a popular web and mobile
SaaS (software as a service) platform many racers utilize to track
their training and race performances. Strava’s v3 API has the ability
to link to courses (called “segments”) and these segments could
substitute for the manual GPX to JS render. More information
needs to be determined, but this could be an integration to scale
the app and the visualization.
3) Security - While there is no financial data, nor home street
addresses, there is data, and personally identifiable data (name,
email, race history and photographs at a minimum) included on this
database. The security of all this data would need to be kept a
close eye as hackers and attackers could exploit it.
4) Tracking - Use of a tracking package to instrument all pages would
be helpful. There are many packages that give more detailed
information beyond simple Google Analytics such as Mixpanel,
NewRelic and Kiss Metrics. Likely I would start with Mixpanel.
5) Skills and Staff - It goes without saying that I am not skilled in
backend operations nor security when it comes to web application
deployment, there would need to be a small staff available to
handle the technical operations as well as some staff able to
handle user inquiries, bug-tracking, and feature requests.
6) Clean data - Every race requires someone to upload results, this
process can become more automated over time, and also, is the
data accurate?