Skip to content

Dagger 2 Migration

rustie edited this page Mar 17, 2019 · 1 revision

Motivation

Berkeley Mobile is an app that has a very predictable structure. We serve static data (e.g. libraries, dining halls, cafes, resources) all the same way, with similar UI structures, so it makes sense to modularize. Previous attempts to modularize were very hacky and were on a scale that would not have much impact on overall LOC.

Moving to Dagger 2 dependency injection will help us better organize our application, especially as we scale out the amount of features we serve.

Design

Main design choice is to abstract backend services and data preprocessing away, exposing only a narrow API. We do this two ways at the moment, to account for two broad categories of data characterized by data velocity -- speed at which data becomes dirty.

High velocity data (e.g. transit real-time locations) are served by our Heroku server

Low velocity data (e.g. dining hall menus) are scraped daily and served from Firebase Firestore. To reduce the load on our Heroku servers, we chose to use Firestore as a cache for our low velocity static data. Scrapers can also be hosted on Google Functions in the future to reduce the cost of operating between cloud providers.

Structure

DAG of Berkeley Mobile Android dependencies.

npm install daggraph; daggraph .

Clone this wiki locally