Building Micro-services with GO | Part2

  • Demonstrating the usage of HttpHandler Interface’s ServeHttp method.
  • Launching multiple Handlers within same Server.
  • Handling of Timeouts.
  • Line #18, is what we require to satisfy the HtttpHandler Interface’s requirements.
  • Line #14, is how we are defining the Idiomatic way of defining the way to initialise the object.
  • As a general principle, we should avoid creating direct objects inside our handlers. The reason for that is : when we start looking at our testability, we should be able to replace those aspects and use something called as Dependency-Injection.
  • At line #20, we have precisely used the injected object of logger, to print something to the logger. This is something known as Dependency-Injection and we shall be using it heavily, when we interact with the databases.
  • Whenever a request comes into your server, the server has a default handler. That DefaultHandler is HttpServeMux. The server is going to then call http.serveMux.serveHttp() function.
  • At line #20, The ListenAndServe() method also takes in two parameters. The first one is port where server shall be listening. Second one is the handler. If we don’t specify anything, it shall be DefaultServeMux. Recall that, DefaultServeMux also implements the Handler Interface. In our case, we shall be defining the CustomServeMux for us.
  • Resources are finite and there are only a limited connections that a particular server can handle. Example → Say a client connects to server and starts doing something and it just pauses, that would be considered as a BlockedConnection.
  • When there are such multiple blocked/paused connections, our server would eventually fail to serve fresh requests.
  • Example → Say we have lot of requests from a single client, we can optimise the same, by keeping our connection open. The Client could potentially use same connection over and over and over again. This is particularly useful in situations where we have multiple micro-services talking to each other and we can be performant by sharing the connections i.e. by creating the persistent connections. As we would want to keep those connections alive, we can keep a Higher value for IdleTimeOut.
  • On the other hand, if we are getting requests from various random clients, then we can keep the value for IdleTimeOut to be quite Low.
  • If we are dis-connecting directly, we stand at a 100% risk of dis-connecting the clients dis-gracefully. Basically, we are saying that : Client is not allowed to finish it’s work-in-progress and this is quite worry-some.
  • Say we are uploading a large file to client OR we are finishing off the database work, we would get enough time, if we have shut down the server gracefully.
  • context.Background
  • timeout → This is the time, that we want to allow to the server to gracefully shut down all connections / requests. If there is any work, which any of the handlers are still performing after this timeout, would be forcefully shut-down.
  • Following are set of dependencies :-
  • Following is how our handlers are tied to the server :-
  • We are starting the server via the Go-Routine, so that it doesn’t blocks the main function flow.
  • Whenever Interrupt or Kill Signal is being received received on system, it’s going to send a message onto the channel. We are then reading the message from this afore-created channel and we know that, we shall be blocked until we receive any message onto this channel.
  • Say we receive either Kill or Interrupt signal, then same shall be consumed onto the channel, then we are going to shut everything down.
  • Here is actual code of our handler, which would serve the Http Requests. Any Go based code, which makes uses of httpHandlers would have to mandatorily provide implementation for the below method :ServeHttp() :-
  • Finally here is how output looks like :-



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
aditya goel

aditya goel

Software Engineer for Big Data distributed systems