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

Rona Chong
5 min readJan 23, 2018

--

In which I continue to work on deploying my app. This post is one day late since I fell sick yesterday! And decided to get some rest. But it’s here now, so fear not. :-)

Previous posts in this series:

(Might have lost proper count here)

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, so my goal for this week was (again) to finish with that and restart my work on the reader module of moshimoji.xyz.

What did I get done?

This deployment journey has been going on for several weeks more than desired :-( but I am actually anticipating the end! I finished setting up my new Docker swarm architecture for stage/prod and worked through errors caused by lack of configuration for prod, e.g.:

  • Frontend (really backend): Network request failed with status 404 — “Not found”
    (The problem: url specs for Django not prepared to take in requests with ‘backend’ slug)
  • Frontend (really backend): Network request failed with status 400 — “Bad Request”
    (The problem: ‘stage.moshi-moji.xyz’ not in Django’s ALLOWED_HOSTS)

After that I moved fixing things for the server side rendering of my app (up till now I dealt mainly with making sure my browser bundle worked as expected, as opposed to the server side response). The first fix was to ensure that an anonymous user be hydrated for responses from my node server (commit here). What I’m working on now is getting Aphrodite (my styling library) to work with server side rendering. I’ve implemented a fix (which I’m not entirely sure will work, since all my usage of Aphrodite is nestled in withStyle calls) but I’m stuck at even evaluating that fix since my app is not behaving as expected. You can read about my chronicling about it here if it so interests you.

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?

  • What I mentioned last week is still my take-away for this week: I was able to diagnose issues fair enough on my own and then work out solutions.
  • I also realized that some of the things I’ve been fixing (e.g. directing my A records to the elastic load balancers launched for my swarm; setting the json web token for the server response) are issues I’d noticed in the past, but left untouched because 1) I wanted to focus on making progress with front-end development in the simplest form (i.e. for the browser side) and 2) because I didn’t yet feel prepared to touch it (I wasn’t fully sure what should go on there). It turns out that leaving those matters till now — after setting up my prod/stage environment — wasn’t such a bad idea, because I have a much clearer picture of what my code is working with.
  • As I dig into errors I find myself reading and sussing out more of the starter code from ReactQL and understanding much more of what is going on with every request to my frontend.
  • Adding more verbose logging in my error handling to provide me the information needed to figure out what was causing issues in prod/stage.

What was difficult?

Diagnosing the issue arising with Aphrodite was a little tricky till I added the logging I mentioned above — but the trickier part was trying to determine which course of action to take once I understood the issue. I could switch away from Aphrodite to a different styling library that would work with SSR by default; I could strip away my withStyle calls and replace them with direct usage of Aphrodite; or I could leave my code intact and hope that the StyleSheetServer.renderStatic function would be able to collate the Aphrodite styles successfully even with the withStyles code in between. The last course of action required the least work but was the one I was most uncertain about working. Finally after studying the withStyles Aphrodite interface, I concluded that it should succeed, but that’s based on more on a gestural understanding of how the interface works rather than a precise one. And of course, right now I’m having trouble evaluating whether the fix is working.

As I was confronted by this issue, I realized that I was lucky that I decided to work on deployment/fixing SSR now, rather than later, because if I tried this after a lot more development, I could’ve discovered that I chose the wrong libraries to work with SSR and have had to replace a lot of those libraries in a non-trivial fashion. So I’ve struck a dicey balance between pending the harder to figure out elements of my app (deployment, ssr) till things are clearer, and pending too long.

What would I do differently next time?

Nothing that I haven’t already mentioned in the past.

One cool thing I learned about

The difference between using the shell syntax vs using cmd syntax for command lines in dockerfiles (the shell syntax will execute the command in a new shell, whereas the cmd syntax will execute in the current shell, which has some implications for things like SIGTERMs and whatnot).

Misc links for your browsing pleasure:

--

--