Piping the request The middleware pattern is an ubiquitous software concept that help us to decoulpe a request process in stages the same way pipeline pattern does. His monoidal nature grants ease of composition, which allow us to reuse any of these stages with other proceses. Moreover, this behaviour arises a declarative way to define our service architecture in semantic terms.
This post will cover the foundations of this mechanism in the HTTP ecosystem, providing some uses to atomize our handlers, and finally showing up the benefits of this approach to define our architecture.
The basic idea: a way to get rid of classes There are many well identified classes that only have a one public method, such as iterators, lexers and that kind of walk-on-collections objects. I call this case a 1:1 class: when a class has just one public method.
class Greet { constructor(greet) { this.greet = greet; } greet(name) { console.log(this.greet + " " + name); } } const salut = new Greet("Hello"); salut.
tl;dr:
from\to io.Writer io.Reader string []byte bytes.Buffer io.Writer – io.Pipe io.WriteString N/A N/A io.Reader io.Copy – strings.Builder N/A N/A string bytes.NewBufferString strings.NewReader – []byte(“io”) []byte bytes.NewBuffer bytes.New{Reader/Buffer} string(byteSlice) – bytes.NewBuffer bytes.Buffer it’s it’s buf.String buf.bytes – Go has become a very popular language, so there’s day to day multiple posts and tutorials. But so many of them are missusing the basic interfaces, and they are a core design concept. Let’s check it:
All the code used here is on my github: pabloos. Keep an eye on it, for clarity I will not reference all the functions. Each section has his own branch.
1. Original Sketch A pipeline is not unlike an assembly line: a queue of jobs that transform an input and sends it to the next stage. In Go an obvious implementation would be based on channels (originally based on an idea in the oficial blog), in which each function represents a separate stage connected with the next one using a channel.
As a backend developer E2E testing is a must for me. E2E testing does not only check the features of the frontend, it cares about the whole system. A good match for this purpose on Node it’s the jest and puppeteer tandem for testing web apps.
(Note: From now on I assume that you have some experience with the API of both technologies)
About the dependencies You will find a bunch of posts about this topic on the internet.