In “A Self-Evolved Microservice Framework in Go”, I described a framework that can evolve itself. It has two pieces, one is the lightweight framework, the other is the pluggable third-party components. You can call this architecture “small framework, big library”. In this article, I will talk about how to create pluggable third-party components. The followings are what you need to consider.

• External interfaces of third-party libraries
• The internal structure of the third-party library
• How to handle configuration parameters
• How to expand third-party libraries

We use logs as an example to show how to create third-party libraries, I named it “glogger”. The Go language has many third-party log libraries, each of which has advantages and disadvantages. In “Go Microservice with Clean Architecture: Application Logging” I talked about that “ZAP” is so far the best logging library, but it is not perfect, I am still waiting for a better one. If there is a better one in the future, I hope that switching to the new one only needs a small code change, which is already supported by the framework I mentioned above. It is because all logging calls are made through a common interface (rather than the proprietary interface of a third-party library), so that only the creation of a logging library is library-specific (this is the part of the code that needs to be modified), while the calling of logging functions do not need to be changed.

#third-party #golang #go