Before we go on to the next step of the project, we need to address some of the hard coded values such as the port we listen to. Magic numbers are always bad and fixed port numbers are especially troublesome. Different enviroments (workstation, dev, test, staging, production) might need to have different ports. This will be a common thing to do so it makes sense to write a library because we should abide by the DRY principle - Don't Repeat Yourself. However, there is a danger in taking DRY too far. A little while back, the node.js community had an issue where a library writer took down a bunch of his code breaking many other packages that used his code. One that I found funny was a library to leftpad strings. This is a very small piece of code to write and probably didn't need it's own library. We're talking CS101 level of code that people pulled down from a library creating an external dependency versus just writing it themselves. I've seen it in the Java world, too. Add a dependency just to get a String.isNullOrEmpty() function.

Now, I'm not saying dependencies are bad. I'm not going to rewrite a database library for instance. Just be aware of what a dependency could introduce to your code. Don't be afraid to write simple helper functions that you may copy and paste in your projects. There are things that are so simple, you likely never will change them. Additionally, where possible, keep a copy of the code for external projects. Go has vendoring. You can always fork git projects. Maven typically allows you to download the sources.

Alright, now that I'm off my soapbox. Webservices will need a variety of config settings and if you're trying to abide by the 12 Factor App (https://12factor.net/) ideals, they should be in environment variables. I really got tired of writing the same parsing code so I wrote a library to do it. The code is available on my github at https://github.com/ericfialkowski/env. We will get into using it for the next step of the speller project.