Let’s Build A Web App! Week 21–23 of my 30 week web dev journey

Rona Chong
5 min readJan 8, 2018

--

In which I painstakingly wrap up some PRs and then start digging into my (virtual) servers! Fun!

Well, dang, it’s been a while. I’m sorry about this — I’ll attribute it to the holidays, which meant that Weeks 21 and 22 weren’t full weeks of work and my would-be blogging dates coincided with Christmas and the New Year.

Previous posts in this series:

(Might have lost proper count here)

Now let’s get back to my well-missed weekly update on what I’ve been up to!

What did I set out to do?

If you have excellent memory, you may recall that last I wrote, I set out to deploy the current state of my app to a Docker swarm, and got stuck on spinning up new Docker for AWS stacks on CloudFormation. My goals were to get unstuck, finish deploying my app on a stage and prod cloud, respectively, and finish developing the reader module of moshimoji.xyz.

What did I get done?

  • Get unstuck spinning up Docker for AWS stacks on CloudFormation
    First I thought I thought the `The following resource(s) failed to create: [ManagerAsg]. . Rollback requested by user.` error might be due to a config setting I gave to the stack, and changed my config to match that of the previous, successful one. After that I suspected it had something to do with VPC network for the stack, so I updated the settings to share an existing VPC rather than generate a new one. Finally, I tried creating a new iam role with administrative privileges to see if it would work. Didn’t make a difference either.
    Finally I resorted to saving the template for my one successful stack (spun up long ago) and using that instead of the official docker template (not sure if there’s been changes since I originally used their template). Then it worked. I probably need to ask on the docker forums or the like to find out why.
  • “Finish deploying my app on a stage and prod cloud, respectively”
    Hah! Not quite. But I made some headway. Here’s the low-down: After getting unstuck with Cloudformation, I spun up two stacks/Docker swarms: one for stage and one for prod. I updated my DNS A records to point to the different swarms according to subdomain. Then I created a compose.yml file that would deploy a Docker stack with services for my frontend and backend, respectively (working through a few errors on the way). I got to the point that my Docker tasks (containers) were no longer failing, but my Django backend and React frontend were both reporting errors from inside the container.
    The first error to resolve for my React frontend was to add logic to set data-query endpoints for a non-development environment (which I’d skipped over so long as I was only deploying locally). Even though it sounds like a small task, I finally managed this after about a week’s worth of work. And that’s where I’m at now.

What didn’t I get done?

  • Finish deploying my app on a stage and prod cloud, respectively”
  • “Finish developing the reader module of moshimoji.xyz”

What went well?

Continuing with my preoccupation with productivity (since I struggle with it), I came up with a weekly routine matched to overall goals for the year. And like usual, I zealously track what I’m doing to compare to my intended behavior. I find that this helps me feel a little more motivated, steady, and aware of how I’m prioritizing things.

What was difficult?

Re: configuring my React app for prod — It took me ages to figure out why an environmental variable I was setting for my node process wasn’t showing up in process.env. Finally, after a day or two of digging around (at one point even running strace to get a better picture of what was going on) I realized that the Webpack config that came with my starter kit (ReactQL) was written to replace any references to process.env in my source code with a different object at build time. From there I had to consider the reasons for this and come up with a solution that would allow me to differentiate between prod and stage at build time.

Me taking several days on this, and several days on the CloudFormation issue, points to a larger pattern I have of taking several days to figure things out (and I’m happy that I’m generally capable of it, but..) — typically you would want to not take too long by consulting people with more expertise when possible. I do have people at my disposal to consult about these things, but when I weigh how much time it takes to present the question to others and get a reply, I’m not sure whether it is better to consult or not. How do people handle this when working remote?

What would I do differently next time?

If a variable or object does not have the value(s) I expect and I’m confounded, search for any assignments to its value(s) in my codebase earlier.

Maybe use Meteor instead of ReactQL for my ‘frontend’ and Django for my ‘backend’.

Maybe start with the simplest stack for getting an MVP done first (e.g. Heroku?), and then create a more ‘sophisticated’ DIY setup later when necessary. Though I definitely do enjoy setting up my own stack.

One cool thing I learned about

I learned a lot about managing environmental variables between processes and NODE_ENV, and process.env. In particular, I realized there was a concern about checking process.env on the server side because of the system calls that get executed, to the point that the Node.js docs now (as of Nov. 2017?) recommend caching process.env in some cases. Also re:NODE_ENV, the React module is written around the expectation that you build either a production or a development distribution, though there has been discussion of supporting a staging option.

Misc links for your browsing pleasure:

--

--