Citrics
The Story of the Web App That Helps Digital Nomads Find Their Next Home
Description & Architecture
Citrics is the first web application I have worked on with a production window longer than a single week. The app is designed help answer a common question plaguing digital nomads, where should I go next? Working as a data scientist on a team with seven other people, we set out to build an app that would allow users to compare certain key metrics for various cities in the United States — hence the name Citrics = “City” + “metrics”.
The application is actually composed on three main components, the web application itself, the Data Science API we built for the application to call from, and a PostgreSQL database which the DS API references. The latter two were hosted on Amazon Web Service, with the DS API utilizing the AWS’s Elastic Beanstalk Service using FastAPI.
Planning
Following Stephen Covey’s advice to start with the end in mind, we began by defining our end goal: producing a web application which would allow its user to compare different city metrics for at least three cities at a time on a single page.
Since my fellow data scientists and I would be in charge of supplying the metrics going into the web application, we set about broadly outlining what metrics would be included in the application. In consultation with a digital nomad currently struggling with this dilemma, we decided to include four categories of data: population, weather, employment statistics, and rental prices. After sourcing the appropriate APIs and datasets online, here are the metrics which were incorporated in the first release of the web app.
Weather
- Raw Temperature
- Temperature adjusted for humidity and wind chill
- Precipitation
- Barometric Pressure
Rental Prices — Apartments
- Studio
- One Bedroom
- Two Bedroom
- Three Bedroom
- Four Bedroom
A Note on the Current State of the App’s Development
Because of the arcane nature of the Bureau of Labor Statistics API and the amount of time invested in ensuring that visualizations of the rental data made it to the API for the web developers to be able to incorporate into the application, population and employment statistics have been left for the app’s second release. Though some of the app’s predictive components which will be discussed below have been built and incorporated into the DS API, their incorporation by the web team is still forthcoming.
More Planning
The three steps of data collection, data processing, and route building formalized onto a Trello board were the extent of our initial planning. As the project progressed, however, and the number the routes grew, the DS API became messy, and increasingly difficult to navigate.
So, I took it upon myself to hold a meeting with my fellow colleagues in which I outlined an API structure showing how each route in the API could be connected to related routes, making navigating the DS API far easier for the web developers, and cleaning up our the messy api directory in the project’s GitHub Repo.
Using the whimsical board, shown below, I was able to explain both the concept of route referencing and how we could use our database to cache predictive search results, thereby reducing the amount of under-the-hood calculations performed by the API.
Fortunately, my colleagues received the idea very well, and we are now working towards implementing the structure shown herein for the app’s second release.
My Contributions
Here are a couple of code snippets with some of my contributions to the project.
This FastAPI route shown here in is truly the essence of Data Science, combining statistical techniques in the form of the Holt-Winters method (Exponential Smoothing) for making time-series predictions into a production setting involving a database. The endpoint returns a JSON string, allowing the predictions to be used by either data scientists or web developers in making visualizations, or by the latter in returning a table alongside a visualization in the final product.
config.js
My reader is likely wondering, “I thought this guy was a data scientist; why did he write this script in JavaScript when he could have easily done so in Python?” And my reader would be right, but that was before I realized that it could be done so easily in Python.
Since my colleagues and I were building the application in a pedagogical setting, we decided for everyone on the Data Science team to gain the experience we would need to be able to secure long-term jobs involving AWS deployment, rather than having a single API deployed, we’d actually deploy a single master API along with individual APIs for each of us to work with after testing each element locally. In order to facilitate this multi-deployment system, I took the liberty of writing the above script and its later Python variant to allow us to toggle between the team Docker account and our personal Docker accounts shown in the Dockerrun.aws.json file, and by extension our personal deployments and the team deployment all in command line.