Our Stack

The application itself is divided into two parts: front-end and back-end. On the front-end, we are using React-Native, and on the back-end we are running a server built on Node.js. More information about how each decision was made for different stack components can be found in our decision making log here.

Front-End

Since our application is a mobile app for Stanford students, it was clear to us that we needed our application to be deployable for iOS and Android based mobile devices. As a way of maintaining one repo for both platforms, we decided to use React Native as our development framework. React Native allows us to use React language along with native platform capabilities for the mobile device.

Redux

Variables that are used across many components are stored using Redux, which is a predictable state container that is used in many React and React Native applications. Our Redux stores two variables: the SUID of the current user (which is used by various components in queries to our AWS database), and the URI to which all queries must be placed. The Redux state is passed down to any connected Component through the Component's props, making it very convenient to get/update the Redux state at any point in the App, and have those changes reflected at any other point.

Back-End

The back-end server is set up using Node.js. The server itself is run in the server.js file. The file imports the routes.js file which creates a router handler to handle incoming http requests with specific paths. The router file provides nice decomposition of request handling into its own .js file. So far, we have been running our server (described in the Back-End section) locally, so the URI that we post requests to can either be a local one (when running the application on a LAN) or a tunnel to someone’s local URI (generated using ngrok). The back-end is connected to an AWS RDS mySQL database (further details below). Location sharing uses a service called Scaledrone which abstracts away some of the infrastructure in automatic message delivery based on channel and room subscription (further details below).

AWS Databases

The AWS database was created to store user, communities, and events data we need in our application. The decision making log has information on why AWS was used, and why mySQL was used as our RDBS. The AWS database contains a single "app_data" schema. Under this schema, there are "communities," "events," "memberships," "resources," "subscribed_to," and a "users" table. Primary keys are either the student's SUID or community name. Below is a visual representation of the tables.

Scaledrone

For location sharing, we used Scaledrone, which is a real time messaging service with a Javascript API. For each user, we create a “drone” that can subscribe to and publish to “rooms,” which are basically pub/sub topics where anyone can publish messages and subscribers receive those messages.