haseebnqureshi / app300 Goto Github PK

Having environment label prefix every database S3 backup. That way, easy to keep track of which data belongs to which environment, for easy pull downs and push ups.

Very hard to understand, and questioning whether code in google strategy should be abstracted further into serialize user...

Both for consolidated EC2 instance and separated between service (DB, API, App)

Whenever we obtain our oauth2 access_token, let's make an additional request for that user's profile information. Starting with Google for now, but placing in a switch to easily expand to other providers.

Actually throw something together and deploy it onto S3. See how long it takes and if everything's good.

Look to passport-example repo and incorporate our previous work into here.

Have to get our styling, components, Vue bolt-ons, etc. into our App. This is the most deficient part of our work, but it's okay -- needed to be the last part.

Be helpful to have expected keys passed into dotenv, and where on the npm postinstall hook, it just populates those empty keys into a dummy .env. Be so much easier to deploy these applications with that, and also helps ensure people get that .env shouldn't be committed or kept in the application's state.

Easiest would be to restrict the IP that's coming into the DB, but that really works easily with separate EC2 instances talking with each other (so having an API fronting the DB). Look through ReDB's documentation on hardening, or at least requiring SSH tunneling to the DB?

How do we handle updates to the framework codebase? I feel it'd be easiest to run npm install and app300 just updates its framework components, and viola. But will that push our milestone out further? Can we get around this?

Gut's saying, don't need it right now -- probably 2nd milestone.

We have the list of so many oauth2 providers, let's create a CLI tool for easy lookup and retrieval. This simplifies the amount of code we're involving into our application.

Go ahead and remove these for now, and/or figure out what's causing these errors.

This is a little hairy if we don't organize this right. If we're on 1 EC2 instance, then one SSL certificate and our other services are at different prefixes -- but could we even run RethinkDB on 443?? Need to research into this and get some solution for encrypted. This could be a showstopper...

No one's really going to be using those optional installations -- and quite frankly, it's hard to follow. Let's make the options a checklist format with one question in the cli prompt, that'll simplify the process.

Get some kind of mechanism for API keys and authorized status. While we're at it, get async fs logging with clearing caches and/or sessions.