For a long time, I considered a filled interface type as an implementation contract in Go. A very quick shorthand on how you can check for implementation compliance is to add the following snippet to your _test.go files:

var _ rpc.UserService = &UserService{}

Until your UserService meets the interface contract, the test will result in failure. You’re likely to add this check to ensure your API is decoupled and can be used behind that interface.

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.