Thanks for the feedback on the previous blog post by Philip Pearl and yimmy149, I understood that I had a fundamental mistake in one of the assumptions I made. As a result, the proposed solution has a bug, as the claim that context is goroutine-scoped appears to be wrong. However, I still believe that the problem statement is correct, and the positive feedback I got encouraged me to improve the design, and offer a better solution.
The context design in Go is beautiful and powerful. But like all things, it also can be improved. In this post I will present the major problems I currently see in the context system, a backward compatible solution to those problems, and a proof of concept library that implements a demo of the solution. Hopefully, you’ll be convinced that this change is necessary and can improve the user experience in the Go language.
Go’s standard library HTTP server supports HTTP/2 by default. It has great documentation, and a great demo page [code]. In this post, I will first show Go’s HTTP/2 server capabilities, and explain how to consume them as clients. Then, I will present h2conn, a library that simplifies full-duplex communication over an HTTP/2 connection.
In the previous post, I gave a short intro to the open API (Swagger) specification, and showed some tooling around it. In this post, I will elaborate on go-swagger, a tool that generates Go code from swagger files.
In Stratoscale, after the standard transition from a monolith to micro-services, we discovered that an “API first” approach with swagger was a good comfortable place you want to be.
We Gophers, love table-driven-tests, it makes our unit-testing structured, and makes it easy to add different test cases with ease.
This is a story about how I tried to use Go for scripting. In this story, I’ll discuss the need for a Go script, how we would expect it to behave and the possible implementations; During the discussion I’ll deep dive to scripts, shells, and shebangs. Finally, we’ll discuss solutions that will make Go scripts work.
Go’s “multiple return values” feature, can be used for several purposes. Among them for failure reporting to the function caller. Go has two conventions for failure reporting, but currently, no clear convention for which to use when. I’ve encountered different programmers that prefer different choices in different cases. In this article, we will discuss the two, and try to make the process of choosing our next function signature more conscious.
There is a trending ‘microservice’ library called go-kit. I’ve been using the go-kit library for a while now. The library provide a lot of convenience integrations that you might need in your service: with service discovery with Consul, distributed tracing with Zipkin, for example, and nice logic utilities such as round robin client side load balancing, and circuit breaking. It is also providing a way to implement communication layer, with support of RPC and REST.