Setting up a dev environment

Purpose

We want people to be able to run the app in their own test environments to not only test new features they want to add, but also to help teach those learning how our entire system works. Either way, we hope that you can learn a few things and if you're a more experienced developer, we learn something from you.

How does it work?

Our entire app is "serverless". To understand how the entire system works, let's start off with our database. We use firestore as our database and store everything from the user drink data to user-specific data (i.e. budgets, limits, etc.). In addition to the data we save on the cloud, we save that exact same data locally in local Storage in a different format. The localStorage data is implemented like a simple database. Each drink is saved as its own entry like this:

"5GeFgkdD45rQgzd5KmMj": {
    "date":"2019-08-16T20:44:00.000Z",
    "description":"",
    "location":"Starbucks",
    "name":"Grande java chip frappe",
    "price":476,
    "id":"5GhFgkdE75rQgzd5KmMj"}
}

where '5GeFgkdD45rQgzd5KmMj' is the unique drink ID generated by firestore.

We also have a separate entry called "drinkids" that looks like this:

drinkids: ["fXReAIuHULOPiFu5YOhm","aX9LrHfCglEE6t66vIRO","ahWFmnm31nOVxm0s4xvw","EMQFsrVVBbk9XyntLFAp", ...]

which is an array of all the drink id's sorted by their 'date' attribute in descending order.

When a user taps on a drink entry in their history tab, the program looks into the entry of the drink id in the local storage and parses the information and displays it in the panel. This allows us to quickly parse and display a drink without having to parse all of the other drinks. On higher end smartphones, we start to see a performance hit after displaying 10 or so drinks and their data.

The way the drinks and their data is stored locally on the phone is also important because it allows us to lower the number of server calls. When we add/remove a drink, we make a call to firestore and they will manage the data perfectly (without worry about the sorted order and the like). However, since we're also storing the data locally we also need to edit our local data. The easiest way to do this is to make a call to the server and replace our data with the updated one on the cloud but this costs us some server calls so I implemented a quick binary search in the drink id's to locally add/remove drinks without making another call to the server.

This seems to be a lot of hoops to jump through just to lower the number of server calls by a bit so the question is why? Well, we're 3 college students who aren't looking to support server costs so that's why. Ideally, you would store all data on the web and leave it at that but notice this way, to display certain statistics and graphs that require math operations on the data set, we would also need cloud functions on firestore which would result in more server calls.

Auth

We picked firestore as our BaaS because of it's simple integration with something like Facebook auth. Authentication is important in this case because of the nature of private data and the like. Since the only authentication we need is a way to separate users' data and set privacy levels, we're not going to be using personal data for our own needs. That makes using a 3rd party authentication service appealing since we don't need to worry about login security and hashing the database and stuff like that. At the end of the day, whatever login system Facebook uses is almost guaranteed to be more secure than whatever we develop on our own. Since our main demographic/audience exists within a Facebook group, attaching more login services such as Gmail, Github, Yahoo, etc. was not a priority and neither was an anonymous user function.

Firebase automatically links our Facebook login auth to an auto generated user id in the main database. That user id is how we know where to store a user's data and we then use that id as our main profile link sharing function. This user id, although unique and a primary key, does not need to be hashed/hidden because there are security rules we add on the firestore client that disallow reading of other people's private data.

Services needed:

With this general description in mind, setting up a dev environment has 2 fundamental steps:

• setting up a facebook app
• setting up a firestore backend

Facebook Developers

First, create a Facebook app. This is how you will manage your Facebook auth. This should give you a client id and a secret client id. It's better to find out how to set this up on the firebase docs but it's important to setup Facebook Auth for the code to run.

Firestore

Next, you want to setup your database on Firestore. After you go through the steps, go into the authentication tab and setup Facebook auth using the keys you got from the Facebook app dashboard.

Finishing up

In the Boba Watch code, you want to first replace our database keys with your own and then try to run it. It might take some tweaking but let us know if there are other details you want me to include here. I'm mostly doing this from memory of how I set it up so do read up on the docs.