Going Old School With Command Line Interfaces for Managing Your Web Apps

My last few projects for West Virginia University have been super simple. In order to keep the back-end management of the projects simple as well I've started writing command line interfaces as opposed to web-based ones. My interest in using command line tools is based on the work I did with the PHP library for ua-parser. For that project I wanted to give developers a simple way to cron out updates to the regexes.yaml file. It seemed natural for me to take that experience and use it in my day-to-day work.

The Benefits of Moving to the Command Line

Moving to command line interfaces for these projects has given me four wins:

  • A lot less code. Authentication code? Gone. Templates? Nuked. SSL-enabled hostnames? Don't have to worry about it. All of the cruft that is needed to host a secure admin web interface doesn't have to be written. It's faster to get up and running as well as faster to modify.
  • Simpler security. The security model now becomes one of access to the server and file. The important caveat here being that your command line utility should be outside of the document root for your website.
  • Better documentation. Because the interface consists of flags (e.g. -f) I have to make sure I provide help documentation in case anyone else needs to use them. It also helps me since I forget them after a while too. The makes for a better solution all around.
  • Cron-friendly. Because the interfaces are written to be accessed and report to the command line it makes it very easy to cron reports and functionality (e.g. getting an updated file from a remote server each day)

The Downside to Moving to the Command Line

"But," you might ask, "don't you become a bottleneck for administering these projects?" I think the natural assumption is that now I can't easily hand off responsibility to anyone else. My experience in the past has been that clients won't, for the most part, take responsibility if they can avoid it anyway. Regardless, the people who would need to pick up the project all have access to the servers so no one is actually locked out. Also, with the documentation built-in hopefully it's straightforward for them to address any issues.

That said, if you're the one and only one who has access to the server or you keep the tool local then, yes, you will be a bottleneck. Understand if the trade-off is worth it.

A Simple Command Line Utility Example Written in PHP

The following is a simple example of what a command line tool might look like if it were built with PHP. By the way, this is one place where I think PHP really excels but lots of frameworks come with similar tools. You could also make your command line tool even more interactive (e.g. ask yes/no questions or similar) but I didn't cover that in the example. See the example on GitHub.

This article was posted