fix: migrate over to AWS for scalability

[nicholaschiang]

Right now, we have a bunch of different branches that correlate with a bunch of different Firebase Hosting websites (e.g. gunn-app corresponds with the tutorbook-gunn Firebase Hosting site) and each of those Firebase Hosting sites has a custom domain that points to a manually configured subdomain of tutorbook.app (e.g. gunn-app is live at https://gunn.tutorbook.app). See #254 for more information on DNS.

Each of those app branches has two commits that are different from develop and master:

1. A commit to change the website to deploy to in firebase.json.
2. A commit to change the website ID (that points to a websites Firestore document) in src/app/packages/app/index.js.

Every time we have a new release on master, I will manually:

$ git checkout gunn-app
$ git rebase master
$ git push --force

On every single of those app branches.

We need to automate those two commits and that deploy sequence along with automating DNS (see #254).

[nicholaschiang]

@gfalqui The other issue that corresponds with #254.

[frankieliu]

There is github CI , do you want me to take a look at that @nicholaschiang https://help.github.com/en/actions/building-and-testing-code-with-continuous-integration/about-continuous-integration

[nicholaschiang]

@frankieliu That would be cool. Let's see if we can set that up and perhaps even migrate our Travis CI stuff to GitHub Actions (that way everything can be centralized in one place).

[nicholaschiang]

Hey @frankieliu actually we're going to re-think the way that we're updating each site. @gfalqui pointed out that each site should be deployed off of master and shouldn't be on a separate branch. I agree with him.

So let's work on changing the way that we get the website's configuration to be more dynamic such that each website can get their configuration without us having to hardcode anything (e.g. based on the current URL or subdomain).

This should probably be worked on along with #254.

[nicholaschiang]

Ok @frankieliu all we have to figure out now is how to deploy to a growing number of Firebase Hosting sites.

We now grab the website configuration dynamically from a Firestore websites document. And we've linked up AWS Route 53 to point a wildcard record *.tutorbook.app to Google's Firebase Hosting servers. We just have to figure out how to deploy our assets to all of those subdomains now.

[nicholaschiang]

@rdelcampog could probably help out with this too!

[nicholaschiang]

Ok, our problem now is that we have to point *.tutorbook.app to the same resources which is impossible to do with Firebase Hosting (we'd have to manually add each record I'm pretty sure). I've got some solutions:

1. We migrate to AWS
2. We figure out a way to programmatically add records to our Firebase Hosting sites.
3. (If Firebase supports it) we add a wildcard record to our Firebase Hosting site.

[OrkhanHuseynli]

@nicholaschiang Could you please elaborate on "subdomains"?? is the problem with the instances of app that you create under different domain names?

[nicholaschiang]

@OrkhanHuseynli see #254.

[nicholaschiang]

Ok, I've configured AWS Amplify and have a live deployment here coming from master.

Now I'm working on connecting our Route 53 configuration...

[nicholaschiang]

I've successfully ported all of our static assets (in build/) over to an AWS S3 bucket that is the origin of a CloudFront Distribution that has wildcard domain rules setup with Route 53.

Working on updating our Travis-CI to deploy there instead of to Google's Firebase Hosting.

And @rdelcampog I'd love some help figuring out how we can have tutorbook.app/app open tutorbook.app/app/index.html with CloudFront. We can configure the default root object but it doesn't help for sub-directories like legal/, docs/, or most importantly app/. See the AWS docs for more info.