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

In which I continue to work on deploying my app.

Previous posts in this series:

• Let’s Build a Web App! A blog series by someone starting their web dev journey
• Let’s Build a Web App! Week 2 out of 30
• Let’s Build a Web App! Week 3 out of 30
• Let’s Build a Web App! Lo-fi Edition / Week 4 out of 30
• Let’s Build a Web App! Week 5 out of 30
• Let’s Build a Web App! Week 6 out of 30
• Let’s Build a Web App! Week 7 out of 30
• Let’s Build a Web App! Week 8 out of 30
• Let’s Build a Web App! Week 9 out of 30
• Let’s Build a Web App! Week 10 out of 30
• Let’s Build a Web App! Week 11 out of 30
• Let’s Build a Web App! Week 12 out of 30
• Let’s Build a Web App! Week 13 out of 30
• Let’s Build a Web App! Week 14 out of 30
• Let’s Build a Web App! Week 15 out of 30
• Let’s Build a Web App! Week 16 out of 30

(Might have lost proper count here)

• Let’s Build a Web App! Week 18 out of 30
• Let’s Build A Web App! Week 19 out of 30
• Let’s Build A Web App! Week 20 out of 30
• Let’s Build A Web App! Week 21–23 out 30

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

What did I set out to do?

I’ve been working on deploying my app for a few weeks now (with the holidays in the middle), so my goal for this week was to finish with that and restart my work on the reader module of moshimoji.xyz.

What did I get done?

• I spent a few hours investigating a network error with my frontend: `getaddrinfo ENOTFOUND stage.moshimoji.xyz stage.moshimoji.xyz:80 ` and resolved it when I realized it was due to a simple mistake (typo).
• I looked into the 500 Internal Server Error for my deployed backend and determined that it was due to differences between my local/dev environment and the staging environment (import errors and so on). After that I resolved to reproduce my local environment as closely as possible in the staging environment, which meant exporting my conda environment (conda is a virtual environment manager similar to venv, but handles dependencies outside of python). Rewriting and testing the Dockerfile to use the conda environment took about 2 days. In the process (pun unintended) I decided to separate out the nginx from the container serving my Django app with uwsgi, because it turns out supervisor (a process manager often used to supervise several processes in one container) doesn’t work with py3.6. I spent another day looking into how I might get my nginx process to communicate with the uwsgi containers, since the ip addresses would vary with spinup. (Turns out the answer is simple because of service discovery with Docker Swarm — thanks Dylan Stein for helping me realize!)

What didn’t I get done?

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

What went well?

Being able to diagnose issues quickly and then work out solutions on my own — learning lots about Docker and virtual system environments. Also, I was able to figure out that a UnicodeDecodeError during Docker build was due to a package readme being read as ASCII instead of utf-8, and find a small update to the package fixing that same error.

What was difficult?

Taking long to implement ostensibly trivial solutions (revamping my Docker file to use my Conda environment; updating my nginx file to work with other containers) because I’m still lacking in experience and so on. I am glad I tweeted about my nginx-Docker question because Dylan’s response to me saved me hours of research, but I’m dismayed that I couldn’t tell how far the swarm DNS resolution went just from reading the docs (and using my intuition).

Also, when installing all your dependencies happens in one step in your Dockerfile (conda env create -f ….), that means every time you change that step or a prior one, you have to go through the whole installation process again with each rebuild of the Docker image. And that’s a slow and painful way to build things! But I wasn’t really satisfied with any alternatives.

What would I do differently next time?

One thing I’ve been reflecting over time is that there’s a certain level of complexity in my app setup/stack that creates extra room for errors or issues and keeps me debugging one thing after another. I personally love doing things hands on and learning this way, and I feel that the debugging process wouldn’t be an issue for a super adept person. But since I’m only adept to figure things out and reach solutions over 1–2 days instead of 1 hour, I’m realizing it would have been better to put out the simplest implementation of my app first, and then work on iterating on the architecture and whatnot with my extra time after that. Part of that would be using a PaaS like Heroku instead of an IaaS-ish platform like AWS; maybe go with Django Rest Framework at first (as opposed to GraphQL, but I think it was kind of worth it to learn the new stuff :) ); skip the server side rendering to begin with.

I thought I wanted a low key arrangement with mentors where I would simply get my questions to them over email, but now I realize how nice it is to be able to just consult someone in person when they’re free, and get feedback quickly. So I probably would’ve set expectations for mentorship differently if I could go back in time.

One cool thing I learned about

I’ll pick out two things I had already kind of tried to learn, but this time really got through to me:

• The difference between conda and venv (which I mentioned above)
• The difference between traefik and nginx in terms of use case (traefik is a proxy that, like nginx, can do some load balancing; but unlike nginx, it’s not a web server, so it can’t serve static files and whatnot. also traefik dynamically recognizes new backends according to the configuration you give it)

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 doc for documenting some travails and clearups during development:
  https://paper.dropbox.com/doc/travailsvictory-log-in-dev-stuff-urw9F3oeUadSzjULXWYiM
• 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