# Should we store sessions on Firebase?

Probably not necessary right now.  We can potentially put a two week limit on cookies, although this can annoy people.


# Should we ditch Firebase?

Pros:
* We never have to worry about maintaining yet another server.  Firebase is either up (most of the time) or down (maybe never).  The firebase API has some good provisions for handling writes during downtime: it just saves all the changes and pushes them all then the server comes back up.

Cons:
* The crazy no-sql database bullshit that you need to put up with.  I hate the idea of storing user specific data in a schema-less storage mechanism.  I've added schemas specifically to deal with this.
* To be more specific on this: this app must enforce the data schema.  Firebase can't.
* Joins are impossible.
* I have no idea how to do backups.

Alternatives:
* Google Cloud Postgres servers.  I have to research to see who is responsible for handling server downtime.

I want to eventually replace Firebase with a relational database setup with replication, backups, etc.


# Deploy notes

Added a folder, `.keys`, not checked into github, containing .env files, ssh private/public keys, and a firebase config files.

Allow public key logins by copying the public key file contents to `authorized_keys`:

    cat ./.keys/staging/bigscreen-accounts-staging.pub | ssh root@138.68.224.54 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Then:

    ssh -i ./.keys/staging/bigscreen-accounts-staging -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null

On the staging server, I'm using pm2 for process management.

For setting up nodejs, I did the following:

    cd -
    curl -sL https://deb.nodesource.com/setup_8.x -o nodesource_setup.sh
    sudo bash nodesource_setup.sh
    sudo apt-get install nodejs