Over the holiday weekend, I put some time into some updates to Sn (the software that makes this blog go) that will hopefully shift it back in the direction I was originally hoping for.

When I initially wrote the app, I hand-rolled my own router function. It was pretty simple, breaking URLs apart at slashes and looking for replaceable variables. It worked very well, was small, and did exactly what I wanted. So why did I update it to the Gorilla mux library?

One of the problems the Sn code is that was all in one file. What I am hoping to do is produce tests for specific units within the application, just like you would for a real live production app. Separating the code into logical files is harder to do with the router the way I wrote it, because it expects all of the code to like in the same space. Using the new library, I can dispatch routes to functions that live in a separate place in the code, making the code more easily separable, and ultimately testable.

This change was not without som interesting/weird side-effects. Previously, I was able to easily forward values included with the route in the configuration file to the template output. This would allow me to send, for example, some titles for a particular page to a generic template for inclusion. This becomes a little more challenging in the new mechanism.

I completely rewrote sections of the application that dealt with static files. I’m actually a bit reluctant to just let the native Go file handlers serve static files, because I can’t really see or control well what’s going on inside there. For example, I am unable to set (at least not as easily) the cache-control headers for files. There is also no log output when one of those files is served, a problem I can remedy by adding long-overdue logging middleware.

I started looking into incorporating some CSS/JS build tools into the application. One thing that I’d ultimately like to be able to do (and am not sure if it’s possible) is to examine the output HTML for where CSS is being included, replace all of those tags with a single tag, and then output a single cached file that includes all of those stylesheets. It would be extra nice if the included stylesheets only included the styles that were used by the site itself, thus removing kilobytes of cruft from CSS frameworks. All of this would need to be cached somehow, of course. Obviously, I should do this only after I get all of the code logically separated into files and tested.

In the end, I think adding the Gorilla library negatively impacted performance. This is disappointing because my prior hand-rolled router was so fast in comparison. It also required that I make changes to the format of my config file that are pretty significant. I think all of this isn’t too terrible, and there are likely optimizations I can make to improve performance. But in the end, if this makes the code more maintainable, it’s for the best.