been writing Go since 2011, have written many http servers, have never really worried about net/http performance.
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.
I totally agree with you and we all know that (I have a good background and experience from my work in docker and kubernetes), but what we are trying is not to solve real-world problem, we are trying to optimize and enhance using different ways / algorithms to build something better and surely we have a vision. Thanks for your feedback
So this provides an http router written on top of fasthttp?
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.
fasthttp is hilariously fast. it's also missing a ton of edge cases over net/http, but yea, it's very silly fast. i'd say just try it and see for your use-case, but expect 2-3x speedup over standard net/http based frameworks at a minimum.
By releasing what is borderline vaporware. Or perhaps a better word would be a noob-trap.
The meat of the project is a router around fasthttp, which presumably is fast because it uses a ternary search tree. Which I fail to see the performance benefits of in this situation, but the point is that even this isn't explained.
I don't want to be too harsh, or discourage innovation, but I do believe there is a net-negative effect on the community when simple projects that could have been Gists are marketed as something they're not. I saw this 100x in the Node.js ecosystem and admire Go because it is kind of the antithesis of that.
I don't agree with you. It does not mean anything if the project has lots of stars and it's not used or useful. gearbox is a trial to achieve better performance than current frameworks.
Here's my issue: If I was a Go noob, I may look at this project and think this is a viable replacement to something like Gin, Martini, or the Gorilla suite.
But since I read the source, I know that it's not much more than a ternary search tree wrapped around fasthttp. And because this is the only thing that is unique about the project, I would expect at least some benchmarks about what makes a TST work faster than other routers. FWIW I am not convinced that TST is necessary. That's why benchmarks are helpful: to prove skeptics wrong.
My point is that releasing an open source framework is a responsibility. And at this point, it's much more likely that future users of Gearbox will have been misled into using a framework that is less necessary, featureful, or proven than others who have real weight and maturity behind them. It's less likely that they are aware of and agree with your questionable, undocumented ideas of what makes a Go framework "fast". I'm sorry for not being supportive, but it's not because I enjoy being an ass: my post above explains why I feel strongly about this.
Got your point and totally agree with you. We are going to mention that it's under development and not ready for production usage till we finish supporting all basic functionalities and have a benchmarks results (also for the current release). Actually, we have things to do more than TST that can improve performance. Thanks for your feedback and we are here to get and understand your feedback :-)
> // 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.
This is because golint complains if you do not write a comment above an exported function. While it does indeed seem silly when reading the code, the purpose is for the go documentation that is automatically generated from this.
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.
I think it's great it forces you to write a comment for an exported function but why the hell do I have to write down the function name again?!? It's literally 1 line below. Can the analyzer tool not grab the name of the function from that?
It makes these comments very frustrating and also more annoying to read because you always have duplicate text.
We wanted to make everything clear. We do routing using Radix tree (https://en.wikipedia.org/wiki/Radix_tree) and we call it routing tree. BTW, more documentation are on way to be added
With the performance coming from being based on fasthttp, what does the framework offer on top? The README doesn't really mention any features explicitly (other than soft ones like "secure" and "fast").
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!
Yes. You are right about that, but we think a bit differently. we think that would be a good chance for contributors that want to contribute to Go projects or frameworks, also tell that we are trying to build something better and surely we have a vision. For the benchmark, we already opened a PR (https://github.com/smallnest/go-web-framework-benchmark/pull...) after running it locally. Thanks For your feedback
"We haven't really done anything useful, but please someone come and make it better"
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.
Don't agree with you. We -gearbox community- are working on improving and adding more functionalities, not waiting as you said. Also, we welcome anyone wants to contribute and help us to make gearbox better. what meant by "solves no real-world problems" was that there are solutions (each one has its benchmarks) and what we are doing is trying to provide it with a better performance
But why market it as "gearbox is a web framework for building micro services written in Go".
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.
Recently, we have mentioned that gearbox is still under development and not ready for production usage till we finish supporting all basic functionalities and have a benchmarks results (also for the current release). Thanks for your feedback
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.