So you’ve built an app that runs on your machine. Great. Now what?
Obviously software is built to be used and today most of that software is being run on servers in the cloud. But sometimes it’s not. Sometimes it might be running on some old hardware in the basement of a company or maybe another developer needs to use your code as part of integration.
Whatever the case may be it would be nice to package your application in such a way that it’s guaranteed to work no matter what environment it is in.
One of the most powerful things about Go is the ability to run parts of your application concurrently. This allows the application to run in parallel at times (depending on the number of cores) or continue to run while waiting for a blocked process. There are a number of concurrency patterns that allow you to structure your applications to get a performance boost.
Recently I stumbled across the “Pipeline” pattern and was able to use it to transform incoming data and aggregate the results.
You should always write tests. To fully understand how to write production level applications in any language you should be able to write unit tests. Some people go to the extreme of doing Test Driven Development (TDD). TDD advocates that you should write tests before you write the code. This can be a good approach when trying to write code that can be easily tested. Yet I find that TDD is a lot like agile; a lot of people say they do it but in reality they do some sort of hybrid version.
In an earlier post I wrote about how to structure Go programs to be leveraged by both a FaaS and a standalone application. This simple application showed the power of what a Hex architecture can do by limiting the need to rewrite logic when an external resource has changed. In that example we looked at changing communication between an HTTP call from an AWS Lambda to a direct application call.