We have discussed about the Adapter Design Pattern in Go and we wrapped the Redigo library to illustrate the concept. During my research I discovered that Redigo has a strong competitor called Go-Redis. I spent sometime playing with it and my first impression was that the code became more concise with Go-Redis. It is also better documented. I didn’t compare their performance, but if we find out that Go-Redis is better than Redigo, what would be the overall impact of switching to Go-Redis?
Well, not much. Since we are using the adapter pattern to hide the caching mechanism from the rest of the code, we know that only a delimited part of the code is assigned to deal with Redis. This part is the struct that implements our Cache interface. But before starting the changes, we need to cover the existing code with unit tests. Here is a sample of the unit tests written for each method of our Cache interface:
The complete set of tests is available in the blog’s repo. With the tests, we want to ensure that the new code with Go-Redis still works like the one with Redigo. It also illustrates how to use the Cache interface, so if we don’t change the tests after moving to Go-Redis then the Adapter Pattern has served its purpose.
The following code is the Go-Redis implementation:
Comparing to the Redigo implementation, we only changed the body of the methods and kept the signatures intact. A complete example of this code is available in the blog’s repo. To check whether everything is still working, I run the tests:
$ cd blog-examples/caching $ go test
All unit tests pass without changes. It means the application can gracefully evolve over time with the freedom to upgrade existing libraries or move to better ones all together without concerns. Of course, moving to another library requires you to perform more tests including integration and performance, but doing it without further code changes is a huge gain.