Simplification is a good thing
Dec 18, 2016
Although PHP is (with good reason) regarded as a bad language, it holds a special place in my heart. It was the first useful programming language I learned when I started getting into coding in my teens, and since then I have used it for everything from simple dynamic pages to large ORM-powered APIs. The former is definitely the problem that PHP solves best, as there is practically no setup or boilerplate required to get a page up and running (if you discount the HTTP server). It’s a technology that is in my experience still unmatched on ease of use for that purpose. Sadly, the web of 2016 has little use for such simple things, and over the years PHP has borrowed so many concepts from other languages that modern PHP has mostly ended up a slightly worse version of them. It has classes, but little type safety. It has collection libraries, but no generics. It has lambdas, but no terse syntax for them. And yet, because of its ubiquity, it’s still widely used for relatively complex systems around the web.
My personal web projects were historically PHP-based because I grew up on free web hosts that allowed PHP, MySQL, and nothing else. But for the last 18 months this site has been running on a $10 Digital Ocean droplet that hosts everything I need, from Ghost to nda to a custom personal finance tool and more. Over time, I retired or replaced most of the stuff that used PHP; not because I specifically wanted to get rid of it, but as a natural consequence of changing interests. But until today, there was one application of mine still relying on a LAMP stack to function, and that’s my game collection app that I sort of mentioned almost two years ago.
This irked me a bit. The only reason I kept Apache on my server was to support this single thing. nginx is on proxy duty anyway, so static files could be served just as well by that. And making a significant change to the underlying technology is one of the freedoms you are afforded when no one but you depends on the project. So for the last month, I’ve been porting the entire backend to something else: ASP.NET Core with Entity Framework Core. C# is a good language and I’m very happy to see that Microsoft is committed to making .NET (and important frameworks) cross-platform. I also haven’t used .NET extensively in a web context before, so it’s been a great learning experience.
The rewrite also made me realize that some architectural decisions didn’t make sense anymore. The old list evolved from a simple
mysql_query() call on a shared web host where MySQL was the only option, but of course, that’s no longer a requirement (and realistically hasn’t been since it started using tools like Composer and npm). Relying on MySQL also comes with its own issues, namely having to install and run
mysqld if you aren’t already. So while we’re at it, we might as well replace MySQL with something more suited for the task. I can think of no better option than SQLite: it’s zero-configuration, it’s easy to manage, and it has first-class support in EF Core. Using SQLite not only simplifies the system requirements for the application, it also simplifies configuration: Previously, you would have to enter a database address, name, credentials, and a table prefix in addition to app-specific options. With SQLite, everything but the last one can be skipped because it’s self-contained and uses no access control mechanism beside the filesystem itself.
gulpfile.js and required Gulp, two plugins, and the tools that actually provided the functionality. With npm, this was reduced to a dependency on UglifyJS and a one-line command in
package.json. If we wanted to add a file watcher that would be one more dependency and one more command. Easy.
So with this, it looks like I can finally retire Apache (and maybe even MySQL), and I have learned a bunch about the .NET Core stack at the same time. I’m gonna go ahead and say that’s a win-win.