vrbtm.co development stream | Week IV
Passcodes, expiration dates, email templates, Mailchimp and deployment.
Not sure what this is, start here with our README, or catch up on last week, vrbtm.co development stream | Week III.
This week, I’ll be working at Chilly Wang’s place while watching the Sunday games. Once again the balancing act struggle is real, but the werk is going to get durn.
Picking up from last week, I’m going to:
- Setup passcode approvals/rejections
- Add expiration dates to content
- Substitute the email stubs with the formatted templates
- Mailchimp integration
Starting off with passcode security. To make this as secure as possible, a passcode will be generated on the server-side when a content request is made. The passcode will be saved in a newly created Passcodes collection against a Content id. Then, on the front-end, the inputted passcode will be sent to the back-end, which will check it against the collection and return a Boolean if it checks out or not.
This actually took longer than expected (~2 hours instead of 1 hour). Mostly because I was expected Meteor methods called on the front-end to be blocking. Turns out, they don’t. I think Meteor implemented server-side console.logs to come through to the front-end which was fucking up my internal reasoning on why things weren’t quite working as I intended. I also modified the methods for approving/rejecting content to accept a passcode. I did this to prevent someone from unlocking the buttons on the front-end with some console magic and automatically getting elevated permissions to approve/reject content.
This still needs some overall styling and error messages. I’ll handle that later.
Onto the email templates implementation. I copied all the template IDs to settings.json and started noticing the client complaining about objects missing. That’s because I kept all of my collection specific methods in one file, and was importing that. Problem is that method specific code needs to be separate from the collection specific code. Especially when you’re using protected credentials that are unavailable on the client.
Anyway, we now have a structure like this for data:
➜ vbmvp git:(master) ✗ tree imports/api
│ ├── collection.js
│ └── methods.js
2 directories, 4 files
The client imports all of the collection.js files it needs, the server imports the methods.js files the client needs. This way, the client only receives what it’s supposed to receive, and anything that’s supposed to stay in the back-end (like creds) are kept there.
Implementing the actual templates was a little tricky. Sendgrid’s example usage docs are slightly off and I noticed a couple of open issues on their Github repo for docs PRs. Maybe I’ll submit a PR after I get this prototype out.
I also added a createdAt field, because that’s probably going to be useful at some point. I’m not quite sure where we want to go with expiration dates. Right now, the front-end is not displaying when the content expires and it actually genuinely deletes the record from the database. I’ll leave this as-is for now.
Last piece before tackling deployment is Mailchimp integration. I started going through the docs, importing a Mailchimp API key into settings.json when I realized that I probably don’t need to roll my own call. Looked into their embedded forms and just ripped out the pieces I needed that are absolutely required. Sometimes, you gotta keep it simple!
Deployment time! Wes has created a Galaxy organization and has invited me to it. I don’t think he has created an account to Mlab though, so I’m going to have to wait until I get that.
In the mean time, I’m going to correct the upload flow. In Wes’s Invision prototype, he directs users to an upsell/upgrade page before taking them to their content. I’ve already coded that page, but haven’t coded the flow through that page.
Done and done. Also added an automatic redirect after ten seconds, because why not. This was a basic exercise of Meteor’s Session package and React’s state.
Wes got back to me with the MLab deets and we’re in business. Made a new cluster, added a database user but I can’t seem to connect to it via the Mongo shell. Noticed that MLab was making a Mongo database with v3.something. Pretty sure my shell is out of date. Going to try updating it.
Going to set the right DNS records for beta.vrbtm.co in GoDaddy. Of course I didn’t accept Wes’s invite in time and it expired. Got him to invite me again. CNAME record set for Galaxy’s DNS at beta.vrbtm.co.
Updating the Mongo shell (via Homebrew) fixed it. Crazy how I’ve done this a handful number of times before, and yet something went wrong with a nondescript error (authentication failed vs version mismatch).
I setup a npm script for deploying the beta called deploy-beta. Galaxy asks for certain environment variables to exist. As well as some changes to settings.json. Made a new settings.json file for beta deployments called settings-beta.json. Now, I can deploy by just running npm run deploy-beta.
Of course this doesn’t deploy smoothly either.
2016–10–10 15:36:34–04:00Error: $ROOT_URL, if specified, must be an URL
I guess it’s not picking up the .co as a domain? I changed the ROOT_URL to http://beta.vrbtm.co and hoping that’ll fix it.
And it works! Prototype has been deployed. Only 44 commits later. A button press later and the excellent Meteor Development Group Galaxy enables SSL.
For next week:
- Harden Meteor even more (remove autopublish package)
- Switch gears to UX, visual design, feature mapping and project management
- Standardize stream of consciousness articles
Wakatime is 5h 54m.
Read the other half of this week with Wes’ VERBATIM Design Advancement | Week IV.