Let’s Build a Web App! Week 2 out of 30
Hi strangers and friends!
You may recall that I am spending 7 months next building out two web apps. (6 months and 2 weeks remaining! If you missed the memo, you can check out my introduction here.) I know, pretty cool deal, right?
This week I had manifold adventures encountering the world of container orchestration (read: wrestling with Docker swarm, reverse proxies and ansible-container), figuring out how a React app may be served, managing DNS records, and a bit more. It’s been fun, though a little heady.
Every week I do a summary of what I hoped to get done this week, what I actually got done, what went well / what was difficult / what I’d do differently next time, and one cool thing I learned about. Here’s the breakdown for this week :).
What did I set out to do this week?
This was the second of two weeks I allocated to setting up my stack and CI/CD process for my first ‘app’, kusamochi.me. Last week I managed to set up a bare minimum frontend (“Hello World” served by an Express web server) on my first Docker swarm (pretty cool!). BUT it only worked in my dev environment, and not my prod environment. That left the following items for this week:
- resolve the issue with my Expressjs app exiting quickly in my remote Docker swarm
- fulfill any additional stack requirements to serve React for my frontend
- deploy my Wordpress REST API and data store stack(s) on my production swarm (in addition to the front-end stack I already deployed).
- get my ‘front-end’ (React/Expressjs) layer to communicate successfully with my ‘back-end’ (Wordpress REST API) (scare quotes to be discussed)
- automate steps for deploying new code, and potentially for spinning up another instance of my swarm
I also wanted to get down my mentors for my projects, which entailed a bit of outreach to people in my network.
What did I end up getting done this week?
- resolve the issue with my Expressjs app exiting quickly in my remote Docker swarm 🙆
I (luckily) realized the issue had to do with my usage of nodemon to run my express app instead of node, and resolved the issue in 1.5 hrs on Monday. - fulfill any additional stack requirements to serve React for my frontend 🙆
After leaving this to the last and doing some grokking to figure out my options, I integrated the build system under create-react-app with the Express framework I already had in place. Research + deployment = 4.5 hours on Saturday (though in the end it was a pretty simple task!) - deploy my Wordpress REST API and data store stack(s) on my production swarm (in addition to the front-end stack I already deployed). 🙅
Blessed be the docker4Wordpress project, which allows you to spin up a Wordpress Docker stack in as little as one command. Unfortunately, the reverse proxy microservice, traefik (awesome software by the way!), isn’t routing requests to different endpoints correctly for me, I suspect because docker4Wordpress’s compose.yml wasn’t written with Docker swarm mode in mind. On the plus side, I can see that each microservice in the stack is up and running. Debugging this one. Research & implementation = 3.5 hours so far between Friday and Saturday.
- get my ‘front-end’ (React/Expressjs) layer to communicate successfully with my ‘back-end’ (Wordpress REST API) (scare quotes to be discussed) 🙅
Didn’t get to it, but, I believe it’ll be a simple task once both stacks are properly set up. - automate steps for deploying new code, and potentially for spinning up another instance of my swarm 🙅
Once I spent some time with Docker and Docker swarm mode, I figured out the basic process to deploying new code and envisioned ansible (which I already used to provision my swarm nodes with software) as a nifty solution to automate that process. But I spent a huge amount of time trying to figure out a suitable approach to automate the provisioning of another instance of my swarm (so I could have stage and prod swarms), only to find out that all the approaches are a little over my head with my current familiarity with ansible, and would take a large amount of time to work out (despite being very engaging problems…
( •̀ω•́ )!!). In the process of rearranging my ansible configuration into a more elaborate setup, I broke what was working for me. So it’s a bunch of push, pull and deploy commands for now. But hey, it’s not too bad.
Time spent on the above: ~8.5 hours between Tuesday and Wednesday. - mentor outreach 🙆
People are nice! That’s what I have to say after sending out a few LinkedIn dms and having people reach out to me on Twitter. Everyone I asked was willing to help. Maybe 2 hours on Monday for this one.
Summary of what was difficult or went well / a thing I might try differently next time
What went well: There were several moments where I started mentally devising my own solution to something, only to stop and do a quick Google search and find that indeed, other people had already made tools or laid out time-saving approaches to solve the same problem (thank you: Create React App, docker4Wordpress, and more). Google before reinventing the wheel.
What was difficult: As a beginner, it takes time to sort out or make sense of new technology, and then judge whether it’s the best approach to take. I remember spending much of Wednesday trying to place the exact role of ansible-container as opposed to Docker swarm, the ansible docker module, and the not yet merged ansible docker_swarm module. Once I did, ansible-container seemed like it would be a cool, time-saving and elegant approach to container orchestration. It took some mindfulness to realize that was dependent on having the technical capital to implement it speedily. In my case, using ansible-container was overengineering.
Clearing up questions with mentors ahead of time would prevent me from spending so much time sorting them out, but another difficult matter is anticipating your questions before trying out a new technology. I wanted to get my questions about React out of the way before next week, but kept stalling because I figured I could ask much more concrete questions if I only tried out developing in React first.
What I might try differently next time: I’m learning that Keep It Simple, Stupid is a really good principle. Also, I want to get better at doing a quick survey of my options for a task (or trying out a task) in advance and sending a queries about those options to my go-to people a week before having to make the decision.
One cool thing I learned about
A service in one network in your Docker swarm can also be registered to several other networks. Useful stuff if you want to use a microservice (e.g. traefik) across several different stacks!
In conclusion
I lied when I said this blog post would be more concise than last week’s. So sorry. I guess I’m just inclined to blab about everything I’m going through. ヽ( ･∀･)ﾉ I’ll try to be more to the point next time.
Even though I only got 3/6 of my planned tasks done, I feel like I’m in good shape to start converting my original website into React, so I’m happy about that. I’ll return to the Wordpress stack as needed but keep moving for now. As for tidily managing knowledge gaps before I start a task, it might be a little late to do that for this project. Luckily, however, I can toggle between different tasks while making inquiries to my helpful mentors. :)
