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

8 min readFeb 26, 2018

In which I fixed my login modal, fixed/refactored a few build things, and did a lot of git things 😑

30 out of 30!!! But no fear, I actually have an extra week left (I estimated 30 weeks in the beginning but I left myself a little room in case I had to finish work ahead of the last day of my specialization. Turns out I don’t have to, so it’s actually a 31 week journey).

We still have one week together. 👍

Previous posts in this series:

(Might have lost proper count here)

Now let’s get back to what I’ve been up to in the 30th week of this journey.

What did I set out to do?

With two weeks left staring down at me, I decided I wanted an MVP + some nice styling to present by the end of this 30–31 week trek. (5 months is a long time to build an MVP, probably, but that’s the result of a lot of choices I’ve made!). My idea for an MVP is a usable reader module and a usable database module. I figured one week for the reader module and one database module would be an even way to split the development time left.

So this week would be devoted to the reader module. As I mentioned last time, the minimum I have left to do to get to an “MVP” for that module involves the following:

getting my React components to query first my GraphQL backend for the assets to pull for a chapter of a series, and then, my Amazon CDN for those assets.

What did I get done?

Fixing my login modal

I picked where I left off last week and looked into the issue with my login modal not rendering properly. My first instinct was that maybe it had to do with Firefox flagging the login form as insecure (something else that I need to address) but it turns out that it has to do with the animation props for react-bootstrap’s modal component. When I set animation=true, the opacity of the child elements are set to 0 but never change to 100 (as it should for the animation). I’m not sure why that is, but for the time being, I’ve turned the animation off so that the login modal now displays when toggled on.

2. Fixing my frontend app with regards to file generation and error handling

After that I encountered an issue where a file wouldn’t generate during build-time as intended, so my frontend app process would get an ENOENT error during runtime and exit. This was only happening in the docker build of my app and not when I built the app locally. I was stumped as to why the chunk-manifest.json wasn’t being generated in one environment and not the other — but I saw a deprecation message regarding the chunking module and so my first assumption was that it was due to a difference in the node version being used.

I went through a lot of pains to update my Dockerfile so that the node version it used match the one in my local environment (8.1.2 instead of 9.something), and in the process I got to the following

3. Refactoring my Dockerfile and incorporating a few other improvements made to ReactQL since I pulled it down

But anyway, using the same node version in the Docker image didn’t do the trick. So then I did what I should have done in the beginning, which was to check if other people in the ReactQL community had encountered this (they had) and if they had identified the problem/solution (they had). The issue was that if no chunking was happening in the app, no chunk-manifest.json would be generated by Webpack. Since the folks on the Github issue made it apparent that an empty {} would work for the chunk-manifest var, I added a try catch clause to catch the ENOENT and set the chunk-manifest to {} if no chunk-manifest.json was available to read.

With that out of the way, I went back to

4. Refactoring my git branches to be independent (as opposed to building off each other) and creating and testing a branch representing the current build deployed on prod and stage

In the process, I ended up

5. Improving some Ansible playbooks to invoke other playbooks related to database migrations and data population only when prompted to do so

and

6. Identifying an issue where running my db-sync.yml playbook doesn’t always populate the data I expect it to in my stage database

I don’t know why this is the case, but I’ve run the playbook once, gotten an error related to having no user statuses in the database to retrieve, checked the database and confirmed that no statuses were present, re-run it, and confirmed then that the statuses were populated and the error was gone. It’s funky as hell to me but for now I’m probably just going to add a check to my playbook for the data to alert me if I have to rerun it to get the stage database to the state I need. On the plus side, I will only need to use the sync for my prod database rarely if ever, since it’s only the stage database that gets redeployed with every re-deploy of the moshimoji stack.

I also ended up

7. Creating a tag for every pull request I’ve merged into my frontend repo

because I got a little obsessive about having development history and I was unwilling to delete my numerous old branches without taking this step. (－‸ლ)

What didn’t I get done?

Everything I mentioned above as things that I set out to do, unfortunately.

What went well?

Picking a kit that’s used well enough that someone shared the solution to a bug 7 days before I encountered it

What was difficult?

The race to keep up with dependencies. E.g. if React gets updated (luckily I started the bulk of my React dev after React 16 came out, I think), there’s a lot of changes I have to make to get my app to work with breaking changes, or even to have my code just use the latest conventions and features of the package.
In this case, I figured from the beginning that ReactQL might have a fix implemented for the (at-first) mysterious chunk-manifest.json issue, but I was afraid to upgrade because I’ve made changes in places that would get overwritten if I chose to upgrade the kit, and then I’d have to do some diffing to re-implement everything I’ve added onto the kit. And I didn’t want to take maybe several hours to do that.
Of course, I could have just looked into what, if there was any, change there was to fix the bug and implemented it myself. (As it turns out, the kit doesn’t have a fix yet, but community members identified what would be one). Which is what I ended up doing, but yeah, it did provoke a small feeling of crisis in me to think about bumping my dependencies. (´・ω・`)
On a related note, my instinct to investigate an issue personally before checking if other people have identified the issue cost me some time this week, as I took a lot of time to update my Dockerfile when the version of node I was using wasn’t really the source of the issue. (Also, I stuck to building on top of bare metal/debian-jessie for so long when I could have used the node image). On the plus side, I’m gaining experience so I think I’m less likely to do that over time.
Ansible when conditions being applied in a peculiar manner for ansible_playbook includes, so that I can’t use them to determine whether or not a playbook gets included.
I think I’ve been dealing with this tension between managing my git history, github repository, and branches/pull requests in a manner that’s easy for other people to look at and making progress with my app development. I’ve accumulated a lot of changes that sometimes build on top of each other, but then I don’t get them reviewed by mentors as I make them because I want to deploy my code first (that way my reviewers could compare the code with the output?). But then I had so many changes to review and so on. It’s a little complicated and I’ve probably spent more time than is appropriate refactoring my git history to make things more digestible, when I need to develop instead.

What would I do differently next time?

rather than operating on instinct alone, imagine solution, THEN CHECK what a relevant repo has done / if it’s added a solution. this saves time
make git tags as I merge pull requests; plan development with tags as benchmarks
NOT rebase/rewrite the git history of the master branch (oops) — now my pull request merges don’t show any more 😅

A few cool things I learned about

http://jaytaylor.com/notes/node/1457984547000.html
https://stackoverflow.com/questions/46580030/ansible-skip-import-playbook-with-variable-definition
https://webpack.js.org/guides/code-splitting/
https://docs.npmjs.com/files/package.json
Folks in node development thinking about using debian slim to optimize the node-slim image: https://github.com/nodejs/docker-node/issues/618
How to dive into containers from images, if your docker container just crashes right after running: docker commit CONTAINER NEWIMAGENAME and docker run -ti — entrypoint /bin/bash NEWIMAGENAME
Postgres: PGDATA, logging_destination, and logging_collector
http://phase2.github.io/devtools/common-tasks/ssh-into-a-container/

Misc links for your browsing pleasure:

My twitter: https://twitter.com/ronachng
My Github repo for kusamochi: https://github.com/ronachong/kusamochi/commits/master
My Github repo for moshi-moji:
https://github.com/ronachong/moshi-moji
My Paper docs for documenting some travails and clearups during development:
https://paper.dropbox.com/doc/travailsvictory-log-in-dev-stuff-urw9F3oeUadSzjULXWYiM
and
https://paper.dropbox.com/doc/2018-02-25-to-x-travailsvictory-log-ZBk0ilIUhFSNY9HxPYnBN
My Paper doc for brainstorming/planning my web projects:
https://paper.dropbox.com/doc/different-ideas-mnesHVM2GY2Fwb05iN2fW
My Paper doc for logging my Google queries (obsessive, I know):
https://paper.dropbox.com/doc/resource-log-rOGTRd8hygvwJ4NCGglpm