For the past weeks, I’ve been working in a personal project that I wanted to do for a long time. Is a programmable proxy.
Load balancer, API Gateway, Cache, TLS termination, and so on, are all example of servers that run on typical stack. But why we need to run all these servers? Wouldn’t be better having all this logic into a single server? And this is the core idea of this project.
The idea is to enable deep customizations at the request path. This customization is done by injecting Go packages, called pipe, to handle the request.
Everything is at a very early stage. I’m gonna focus now on the little and important things like the docs, logs, and metrics.
However it requires well tested code which is not easy to produce without highly skilled programmers which are in short supply.
Most code is produced by people who are learning the products they are working on and are not in a position to redesign the basics when they realise how the whole system should work. After many years of adding features to basic designs, many products are designed by historical accident.
Really the code should be self documenting needing minimal comment. Compare this with the code for net/http.
With computers that are a millions of times faster than the one which put Apollo on the moon why do we need load balancing for the vast majority of installations ? Maybe because software bloat is out of control.
I wish you well on your project and will watch with interest.
You’re correct about the quality of the packages, and by itself gonna be the whole challenge with this project.
Don’t know what the future holds for this project, but the idea is to become a “programmable proxy framework” and on top of that add well-tested packages, ideally created by the community, that does the things needed for an HTTP server/proxy/cache/…:
Rate limit
Routing
Load balancer
A/B testing
etc…
But there still the problem of someone doing a panic inside a goroutine and the whole server going down, not everything is an improvement, unfortunately. But some problems can already be solved, this is a snippet from the configuration file:
host {
endpoint = "api1.com"
handler = "teama.Handler"
}
host {
endpoint = "api2.com"
handler = "teamb.Handler"
}
pipe "github.com/sample/teama" {
version = "v1.2.0"
alias = "teama"
}
pipe "github.com/sample/teamb" {
version = "v3.0.5"
alias = "teamb"
}
The pipe handling the request can be different for any host. So, it’s actually pretty safe. If something goes wrong, goes wrong only at that domain.
When I started programming in GO I was concerned about panics taking down the whole system and started putting defers everywhere to catch them.
After a break I started a new GO project this February and find that the tested code I produce does not require the defers… In fact I had forgotten about the issue until I read your last reply.
My thought is that if you are writing commercial net based software rather than a pretty website then you should be using TCP rather than HTTP as the foundation of your system.
I does seem that GO is the best product available at this time
Yea, usually I use recover when I’m dealing with goroutines that could possibly panic. At PipeHub there is a recover around the dynamic code to catch panics.
TCP support is planed. I already did a change in that direction. Earlier this is how a config was made:
Yes, it’s similar to Caddy. The projects diverge on how they operate. Caddy has a clear focus on its configuration file, like Nginx. PipeHub goes the other way with a very minimal configuration file and handling everything at the Go code.
I already told this at Reddit, and to avoid misunderstanding, gonna repeat here. By no means I’m saying that Caddy is worst then PipeHub, they are just different.