Tego microservice framework

Spent several hours on my Ied Holiday to continue Tego , it’s heavily inspired by go kit. Now I’m convinced that go kit has good balance of flexibility even though it’s far from echo on the easy to use side. However I can say that this structure allows code with 100% test coverage easy to achieve.

On Tego I was literally copied go kit endpoint’s code and adding set for ergonomic. Other than that there are several simplifying here and there. Lot’s of time spent on creating the sample apps to dogfood the tego itself, you can definitely create a complete by following the autocomplete example.


Intercepting Http Response writer in Go

Sometimes we have to use http handler written by external library which we don’t want to change. It’s all fine until we need to know what the handler does, like what is the status code written to the response header.

In Go net/http it’s not possible to read the response directly for many good reason. Luckily ResponseWriter is interface!

Here is example of the interceptor, to get status code.

type HTTPResponseInterceptor struct {
	StatusCode int

//NewHTTPResponseInterceptor create new httpInterceptor
func NewHTTPResponseInterceptor(w http.ResponseWriter) *HTTPResponseInterceptor {
	return &HTTPResponseInterceptor{w, http.StatusOK}

//WriteHeader override response WriteHeader
func (i *HTTPResponseInterceptor) WriteHeader(code int) {
	i.StatusCode = code

The usage is pretty straight forward, wrap the writer with the one from the interceptor. Below example is how I used in my toy project, to get status code then update echo context status code.

func (i *Index) GetIndexHandler(context echo.Context) (err error) {
	i.bleveGetIndex.IndexNameLookup = func(*http.Request) string {
		return context.Param(i.indexNameLookupKey)
	w := util.NewHTTPResponseInterceptor(context.Response().Writer)
	i.bleveGetIndex.ServeHTTP(w, context.Request())
	context.Response().Status = w.StatusCode


I need 2 hours to come up with this solution, but it’s worth the time.
Quick googling give me this blog post which does exactly the same http://ndersson.me/post/capturing_status_code_in_net_http/

TCP Socket Implementation On Golang

Golang is surely my first to go language to write web application, it hides many details but still gives a lot of flexibility. Recently I did strace to an http service app, actually did it without a reason but I found something interesting.

Here’s what strace -c gave me :

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 91.24    0.397615         336      1185        29 futex
  4.13    0.018009           3      7115           clock_gettime
  2.92    0.012735          19       654           epoll_wait
  1.31    0.005701           6       911           write
  0.20    0.000878           3       335           epoll_ctl
  0.12    0.000525           1       915       457 read
  0.02    0.000106           2        59           select
  0.01    0.000059           0       170           close
  0.01    0.000053           0       791           setsockopt
  0.01    0.000035           0       158           getpeername
  0.01    0.000034           0       170           socket
  0.01    0.000029           0       160           getsockname
  0.01    0.000026           0       159           getsockopt
  0.00    0.000000           0         7           sched_yield
  0.00    0.000000           0       166       166 connect
  0.00    0.000000           0         3         1 accept4
------ ----------- ----------- --------- --------- ----------------
100.00    0.435805                 12958       653 total

There are a lot of interesting things in that profiling result, but the highlight of this article are the error number of read and the number of futex call

At the first sight I didn’t think about futex call, which most of them are a wake call. I thought that this app serve hundreds req per second, it should has many go routine; At the other hand it also leverage channel, it should has many under the hood blocking mechanism. So a lot of futex call should be normal, later I found out that this number was also from other things -will back to it later-. Continue reading