Gearbox – A web framework written in Go
github.com
github.com
the bottleneck is usually the storage layer.
let's say you have no storage, your bottleneck is probably serialization.
let's say you don't have serialization problems (except for net/http, optimizing which you could argue is a deserialization problem), what is the problem-domain that's being tackled where you have cpu-bound http performance problems where you shouldn't just use udp instead?
let's say you have no storage or serialization problems, you have a lot of http traffic. if the whole thing is stateless, you add nodes behind a load balancer and call it a day.
ok, none of those things apply: you're dealing with a CPU-bound, stateful http server with all of its state in memory, and it's not fast enough. you are, presumably, at scale and have customers or users; if you weren't at scale, you probably wouldn't be facing this sort of performance problem. so you use something like fasthttp to help you ... scale one node to a very large size? um, I guess you could do that, but now you have a lot of traffic and you've scaled a single point of failure. I just don't get it. I don't get what actual real-world problem this solves that isn't imaginary.
sorry, what? With all due respect why should anyone bother using this framework then?
Why would this be better to use than something like Gin, which has way more features? I would update the docs to be clear about that. What is the advantage of your custom router implementation over others?
Neat project, but it’s hard (at the moment) to see why this would be useful over some of the more mature go web frameworks.
Edit: obviously performance is important, but how much faster is it than gin for example if I am going to be giving up features for speed.
> // constructRoutingTree constructs routing tree according to provided routes
> // gearbox implements Gearbox interface
> // New creates a new instance of gearbox
It's obvious from the names of the functions WHAT they do. The point of the comments are to tell me WHY they are necessary. The project feels like commenting for the sake of commenting. I honestly don't know why a "routing tree" is necessary and how it's helping.
The problem I have with Go is that it does not show an object implements any interface. The implementation is implicit, i.e. you implement the method signatures, and you implement the interface. That particular comment is actually quite useful.
See https://golang.org/pkg/net/http/#NewRequest for an example of this in action where the comment is essentially worthless, and this comes from the go std library.
Go's stance is that it is better to always have people document exports, even if some are trivial and duplicates, it is better to always enforce it so that comments are there for the exports that do benefit from a "why".
If you really hate the comments, in your own projects you can use Revive which is a drop-in replacement for golint and allows you to disable lint rules like comment annotations.
It makes these comments very frustrating and also more annoying to read because you always have duplicate text.
This might've been fixed in Go 1.15 though - see https://twitter.com/bradfitz/status/1256348714198654976.
A comparison with other fasthttp-based frameworks like https://github.com/savsgio/atreugo or https://github.com/gofiber/fiber would also be interesting.
Or maybe a benchmark along the lines of https://github.com/smallnest/go-web-framework-benchmark.
Looking at the commit history (7 commits, most of them from yesterday), the open issues (no way to define URL path variables yet, https://github.com/abahmed/gearbox/issues/15), and the release being v0.0.1, maybe it's a bit too early for a ShowHN?
But if you have a vision of how it will be different and better than existing frameworks and the willingness to keep working on your project, then honestly good luck with it, it might become interesting in the future!
This is why we have so much crap on GitHub. OP has admitted this solves no real-world problems, and I would argue there is nothing wrong with net/http that it would require anyone to bother installing this stuff.
If it's not production-ready, who are these micro services for?
It just seems not even close to polished enough to share it with the wider community. Someone may take this at face-value and try and use it for their own purposes, only to discover it's a purely academic pursuit with no actual merits other than 'oh we might be able to spuriously improve performance.'
I think other commenters have got it right in saying that processing requests is _not_ the bottleneck of most micro services, but interaction with a storage layer or network speed.