go-kit is one of the most complete and flexible toolkits for developing microservices in Go language. At the same time, the learning curve of
go-kit is steep. In this post, I’m trying to explain
go-kit fundamental components using general purpose client-server model of Linux.
General Purpose Client-Server Architecture
A server in Linux binds & listens on a port, accepts connections and server requests. A client creates its own socket, makes a request to the server (IP: PORT). The request is just a buffer. The server spawns a thread or runs the handler in the same process. The handler is a function that understands request parameters and typecast it to its expected type.
The client receives a response from the server. The response is read into a buffer and then interpreted.
go-kit in Client-Server Paradigm
go-kit helps create a service. A service listens on a well-known port and IP. It is the server equivalent of Linux server. The server defines handlers for different types of request (PUT, GET, POST). A handler is a function called for a service request. The handler is a generic wrapper over service specific business logic implementation. A handler for GET call may eventually call
get_status_reservation() in a sample reservation system.
go-kit intends to keep the core logic away from
go-kit influence. The core logic (set of functions that your service implements) stays in a file called
service.go. The remaining
go-kit code tries to access these functions in an abstract manner. There are entities called endpoints, transport and server. Each of these allows a generic interaction of service functions through HTTP (or gRPC).
The overall objective is to expose service functionality through
It defines the send and receiver buffer structure. Each service API could expect and send different data. The transport defines structures that define request and response for each API
In the next post, I will share endpoints, the most interesting part of