When it comes to application design, I’ve formed a few opinions backed by experience. The most important one is: structure matters. In my first years of development, I’ve built a CMS system that was copied over more than 100 times for different web pages. You don’t get there unless you repeat the same process over and over.
Application development is like that. If you’re writing one middleware, you want the process to be repeatable for each following middleware.
A “modify after write” error refers to a situation where a program or process attempts to modify data after it has been written or committed to a particular location or state. In Go terms, this can mean that a field may be modified after the struct has been written to the database.
When debugging a login issue, we found a field was not updated in the database. On investigation, I found that a field in the user data was being modified after it had been saved to the database. Fixing it was just reordering a few lines of code.
Don’t optimize prematurely - but have a plan how you’re going to do it. With the services I write, a lot of the code may be clear, simple and readable over actually optimizing for speed. Sometimes, the difference between that code, and the optimized code, is a short refactor.
When it comes to logging in your Go services, the immediate package to reach for is the standard library log package. As it happens, you’ll outgrow the log package needs almost immediately, because the log package is able to send the relevant logs only to one io.Writer stream, by default sent to os.Stderr.
