Week 14: A Recap
Previously, on 200 OK
Theory is only good if it holds up in practice as well. So last week’s resolve to use Preact for my dynamic frontend pages was put to the test. Since Preact has a React-compatible API, I was able to leverage all the learning resources available for normal React, including Fullstack React, a Frankenstein-esque compilation of chapters from many different authors. It’s a strange book, and I didn’t like it much. It felt like a disjointed experience, badly layouted and obviously updated in a select few places over time to reflect recent developments in the React ecosystem.
In the end, I was still able to make sense of React Hooks and their (admittedly pretty clever) functional approach, even though most of my actual learning came from the official React tutorials and the documentation.
But not everything was joyful with the tiny, minified Preact/HTM package. Debugging became a nightmare thanks to the minification: every error thrown by Preact referenced the single line of its JS source file and some obscure, minified variable name. Plus, the helpful Preact Developer Tools, a browser addon to inspect component state, doesn’t work with that particular library, essentially creating a black box framework whose internals were really hard to inspect. Tht’s not an ideal learning environment. More than once I was scratching my head at some obvious infinite render loop (sending my laptop fans into a spinning frenzy) that was impossible to debug. The DOM gives no hints as to what happens in Preact‘s VDOM and I can only resort to
console.loging stuff to narrow down the search for the error. I may have been a bit stubborn in my decision to not add a build step to my frontend code, but I was determined to not let those comparably small parts of 200 OK become bigger than they needed to be.
In the end I managed to complete the actual implementation of both the dashboard and the request/response inspection tool and the live version at 200ok.app is now fully functional in that regard.
A good amount of time was also spent on trying to solve a mysterious timeout issue with the server-sent events. While they worked great, after 60 seconds of idle time, Firefox always reported that the HTTP connection used for transmitting events was closed. This was strange, because it turned out that this didn’t seem to be a Node-related issue. Node sockets time out after 120 seconds by default, but even after configuring those settings, the timeout persisted. Since I’m not an advanced networking programmer, I ran out of ideas, since I wasn’t even able to determine with confidence whether the timeout occurs client-side of server-side. My (ingenious) solution was to implement a regular heartbeat, that sends an empty comment line every ten seconds from the server to the client, keeping the connection open.
If it works, it works.
Coming Up Next
This week is starting a bit slow, but I’m determined to finish the endpoint behavior customization for APIs and implement most of the backend functionality that is still missing. That will hopefully leave me with bugfixing and refactoring as well as the looming task of writing my case study. I’m really not looking forward to that.
Time spent this week: 38.5 hours