Firebase

Firebase is the backend service used for the TAMUSHPE app. It is the place where all data shared between devices is stored.

Firebase Services

On a high level, this is an overview of all of the services we use:

• Firestore - Stores JSON text data in different collections.
• Storage - Stores any blob-data (non-text data).
  • This includes images, video, pdf-files, zip files, backups, etc
• Functions - Creates API endpoints that can be called from the app.
• Auth - Handles authentication in the app through email and OAuth.

Each of these services

Firestore

Firestore is where the majority of text data is stored. This includes user information, committee info, event logs, and anything else that can be stored in a JSON format. JSON files are essentially text representations of Javascript Objects. If you're coming from a python background, these are very similar to dictionaries. The following is an example of a document that might be stored in firestore:

{
    username: "Bob",
    bio: "Hi, my name is Bob. I am a CSCE major planning to graduate in 2027.",
    roles: {
        admin: false,
        reader: true
    },
    interests: ["Study Hours", "Workshop"]
}

Firestore layout

Firestore works with collections, which act similarly to a files system on your computer. If you are given access to the database directly, you may see this in action here. The following is a visual representation of how the app data is laid out in firestore for the app:

committeeVerification
\
 --------------------<Committee Name>
                     \
                      ---------------requests

committees
\
 ---------<Committee Name>

config
\
 -----<config document name>

deleted-events
\
 -------------<event id>
              \
               ---------logs
events
\
 -----<Event ID>
      \
       ---------logs

feedback
\
 -------<Document ID>

links
\
 ----<1, 2, 3, 4, ...>

member-of-the-month
|
\------------------member
 ------------------past-members

memberSHPE
\
 ---------<User ID>

office-hours
\
 -----------<User ID>

restrictions
|
\-----------blacklist
 -----------watchlist

resumeVerification
\
 -----------------<User ID>

resumes
|
\-----------------data
 -----------------status

shirt-sizes
\
 ----------<User ID>

users
\
 ----<User ID>
     |
     \--------event-logs
      --------private
              \
               ------privateInfo

File Paths and Subcollections

Each individual Firestore document represents one JSON object, but they can also store subcollections. These are collections that are inside of documents. This can be useful if something needs a logical list of documents or if certain information requires different access permissions.

SHPE Events are a good example of why someone would need to use subcollections. Each event has a document with a unique ID for that specific event. These events must also track who has signed in to collect points, so they have a subcollection named "logs" which stores information about who has signed in.

Users use subcollections as well because a user may have private information that is useful to the app or officers, but other users should not see. This includes things like emails or push-notification tokens.

Collections and documents have a special rule where a file path must be alternating between collection and document and there must be an even number of tokens in a single file path. This also means there must be an odd number of tokens for a collection. Here are some examples:

• Valid file paths
  • collection/document
  • collection/document/subcollection/document
• Invalid file paths
  • document
  • collection/document/document
  • document/document

Storage

Firebase Cloud Storage is where we store blob data. This includes things like images, pdf files, and database backups. Compared to Firestore's subcollecttion structure, its file structure is a lot closer to a traditional file system. There are directories and files that the directories contain. Directories can also contain other directories.

A major advantage to cloud storage is that it essentially has a built-in CDN (content delivery network) and every file has a link associated with it. This means that pictures can be put in the app relatively easily.

Functions

Firebase Cloud Functions serve as our primary backend for performing operations that a user should not be able to perform on their device. Because theoretically anyone could connect to our database and do what they want, we don't give everyone access to create/modify/delete just anything. Cloud Functions create API endpoints that our app can call which do those modifications securely and in a way that doesn't allow the user to do whatever they want.

A good example of how we use cloud functions is with SHPE events. When a user signs in to an event, their app sends a request to a cloud function named eventSignIn. This then takes the time of the request, location the user gives, and calculates points accordingly. We would not want a user's device to do this on their own, because that would mean that anyone with basic JavaScript knowledge could sign into any event they want or even give themselves 1,000,000,000 points. Because of this, we use the cloud function to do the work instead.

Auth

The firebase Auth service handles logging into the app. We use both OAuth (sign-in with google) and email services. OAuth is used for the TAMU accounts because it makes things a lot simpler and email is used for guest-accounts.

• Note that OAuth does not work with Expo Go, meaning if you work with Expo Go you need to sign in with a generic account.

Code Examples

Theory is great and all, but doing things practically is also pretty good.