-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Are there frameworks based on fasthttp? #9
Comments
Unfortunately there are no frameworks with fasthttp support yet :( Because fasthttp is very young - it has been started a month ago. Everybody may help by filing feature requests to their favorite frameworks, asking to add support for fasthttp. I already filed such a request for httprouter. |
Hmm. I just stumbled upon this project 2 minutes ago when looking at fasthttp. I'm getting frustrated with many Go frameworks:
I'm somewhat interested in building a framework for this. I've already been building a very simple framework that has built in security features, such as rate limiting and authentication for a user built in. It'd be nice to have a refreshing restart of the middleware ecosystem, although some would argue more or less removing support for a large sea of code is a bad idea, even if is mostly unmaintained. I guess I could fork other middleware and port/improve them. I have a few questions:
Thoughts? Comments? Questions? |
I think there is a good case for a Go web framework that is on one hand very fast but on the other hand can increase our productivity as developers. That's the reason this project is so popular. It provides the building blocks to create such a framework. |
I like the Martini style as it looks clean, although the documentation with so much reflexion is cumbersome and it makes code completion look quite odd. That's not mentioning speed trade offs.
Yes, although I might argue that fine grained control is better than abstracting too much away, especially when it may be “leaky abstraction” (a reference to a Joel on Software post). If you have to think about what goes on during the request, it can be cumbersome when the framework doesn't let you control every header and every part to tweak (when you need it) how your API/website functions. The challenge is finding good defaults and having interfaces to change things without too much thought on the programmers behalf. To be perfectly clear—I don't think a simplest for beginner would be the best route for a framework built on some of the fastest server code around open source in Go. I'd expect the demographic to be more experienced users building for medium to large scale production environment. Can I ask you what API you would recommend for functions? I think it'll be something like this: var s framework.Service = framework.newService()
func indexHandler(c *framework.Context) {
params := c.Params()
c.WriteHTML("<html></html>")
}
func init() {
s.HandleGET("/", indexHandler)
}
func main() {
s.run(framework.Settings{})
} I use init to break handlers into separate files easily. RE dependency injection: I'd imagine this would be a job for a side library, not this itself. I'm not exactly sure what you're proposing for this to be linked into the framework. Can you elaborate? |
Yes, it already serves high volume traffic in production on multiple microservices.
I'm ready to help developing decent router for fasthttp (if it satisfies the following requirements: fast + clear API. See below for details). I'm going to maintain fasthttp in the future.
I have zero experience with http routers (both as user and API designer), so cannot distinguish between good and bad API for http routers. So probably somebody more experienced should help you with this.
Just posted an announcement on golang-nuts. I'd recommend avoiding the following stuff, since it usually increases code complexity and complicates debugging. Especially in the hands of inexperienced developers:
Performance optimization may be added to this list as well. But this is good trade-off for good fasthttp performance :) |
Do you see a need to build an entirely new router? If httprouter isn't too entangled with the standard http library, I'd like to port it since it is super fast compared to some other libraries. Anyway, I'm curious what you consider to be a "simple" API—are you talking about essential complexity or accidental complexity? To what degree? And no, code generation is not a force I want to mess with :). I don't like when you have to download new tools to use a framework when it's not needed. |
I don't know anything other than dependency inversion that can isolate a component correctly. |
Hold on; I'm slightly confused now. Inject what? Are we talking about handlers or an extra API feature unrelated to the core? I was talking about handlers and I thought you were talking about an unrelated feature. If you're talking about handlers, can you explain why/what you would inject related to the handlers that needs to be built into the framework? I think we're talking about different things. |
I'm talking about injecting dependencies for a request such as the database connection pool. |
Is there a reason that has to be integrated into the framework or can it be a separate library, like Dagger? |
Productivity. Plain and simple. |
Actually, httprouter's author, @julienschmidt, left the following comment on the feature request for adding fasthttp support to httprouter:
As for dependency injection, reflection, code generation and other bikeshedding approaches for http router, go on and implement routers with these features (or anti-features, depending on personal opinions :) )! While I don't like these 'features', there are a lot of people who want using them.
I usually create a separate package exposing database-related API and just use it in request handlers. |
You don't like magic? Aww, no fun! :)
How do you mock the database functions without dependency injection? Wouldn't you have to create a mock object for the database functions and then inject this object into the handlers for unit testing? That's what I think of when I think of DI is mocking for unit testing, although I suppose it could be used for other things. Anyway, the only dependency injection functionality I would want to build in is if we integrated a testing features set, which is down the road, but would be useful as debugging handlers are very difficult to do. More short future: I am thinking for httprouter that we request that we create an interface for all http communications. The only times a router should have to deal with the http connection are:
We wouldn't be able to do everything through an interface, but keeping everything contained would make it easier to update with the fork if we could separate the parts a bit more. On GitHub: Manual collision "fixing" will be a near daily occurrence when pulling from upstream, but it'll mostly he function declarations that cause the issues. |
I don't mock database functions - I just connect to test database in tests :) While dependency injection is good for unit tests, it is not so good for integration tests and production debugging. Additionally, I don't like mocks, since:
|
FYI, try the first router based on fasthttp - https://github.com/buaazp/fasthttprouter . Thanks, @buaazp! |
I saw that, and it looks like a good start. I'm hoping to get a start this Sunday as I've been busy tidying things up before the end of the year and getting ready for the holidays. I'll have some full days in the next two weeks to chip out some parts and possibly even get a very simple, but working, framework released to get feedback before polishing and packaging an alpha for official release. |
Status update:I'm starting development on this again after a week break (this is a side project so development is slow). Currently at 1666 LOC; most of the remaining API planned out. Expecting to double in size after tests (which are mostly copy/paste and not hard architectural decisions). I've built it so it can be used on top of fasthttprouter/fasthttp OR Gin. Yes, a framework on a framework is redundant, but it's meant so people can use Gin's handlers with my framework to help make porting smoother. In addition, it might be more appealing to use fasthttp if they know they can easily switch to more stable software in emergencies. The rest of the work is tiny implementation details/small refactorings, docs, testing, etc. that should be done before it goes public. I'm emphasizing stability and prettiness at first, but later I will start optimizing. I have a few places that |
@Anon-Penguin , this sounds cool! Keep it up! |
At home sick, thinking about API and I want your opinions. The current API passes the handler a However, I can't figure out a clean way to handle responses. I have refactored it a few times feeling unhappy with every iteration. I'm trying to get the user to use functions instead of response codes; they would do Functions like these cause two issues:
My solution was to create responder objects for each type of response that you can use like this— // S = service object
s.GET("/hello", func(c *pkg.Ctx) {
pkg.ResString{c}.StatusOK("Your request was responded to correctly!")
}) ( Does this syntax feel heavy? Thoughts? Am I completely overthinking this with having separate functions for each status code? I don't know if the extra typing/remembering (presuming you don't have code completion) is outweighs the benefits of less unnoticed typos. Other API stuff: this framework is trying to appeal to a broader audience, so I disliked the "do not use strings/[]bytes returned from it after handler returns" rule because it is more likely to create bugs when passed to libraries that store them long-term. Instead of this fasthttp behavior, all of the strings returned are copies of the For this framework, I can only pick two of these: speed, syntax, safety. The line is not always clear :) |
@Anon-Penguin , I'd suggest starting with minimal API providing orthogonal functionality and then adding helper methods for frequently used code. |
@Anon-Penguin I wouldn't be so concerned about status code typos, we can always use the constants from the package. |
Just FYI, there is new router with fasthttp support, which is based on ozzo-routing - see https://github.com/qiangxue/fasthttp-routing . |
FYI: Labstack Echo V2 supports fasthttp and is already one of, if not the fastest routers / frameworks for the std http lib. I can highly recommend it as a Go micro framework. |
@CaptainCodeman , just added |
@CaptainCodeman Nice. I used Echo before and it's pretty awesome. |
To give fasthttp a try I just switched an image service running on AppEngine Managed VMs to use echo + fasthttp + libvips ... seems to be running great! It's hard to judge performance with so much blob-store loading and caching involved but I'll get a better idea of the impact looking at the overall perf load after a few days. |
Closing this issue, since certain frameworks already support fasthttp. These frameworks are mentioned in the FAQ. See the question |
great job . thanks for open |
I mainly need a good router but a complete framework will be nice.
The text was updated successfully, but these errors were encountered: