Skip to content
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

Start concrete comparison list against other current implementations #5

Open
djui opened this issue May 25, 2017 · 2 comments
Open

Comments

@djui
Copy link

djui commented May 25, 2017

I really like the education benefit for the community of this project. I think the project has potential to educate router library and middleware authors to make their own implementation more robust and reach higher-quality implementations.
Thus, I would like to suggest a comparison list being added to the readme that outlines current "imperfections"/differences of other major router library providers.

I think a good start would the https://github.com/pressley/chi router and their https://github.com/pressly/chi/blob/master/middleware/wrap_writer.go middleware responsewriter. It always looked very complete and modern to me with their support for 1.8 and http.CloseNotifier, http.Flusher, http.Hijacker, http.Pusher, and io.ReaderFrom interfaces. But now I got sceptical.

I understand this list has potential for blame-gaming but I believe written in an informative and as-neutral-as-possible style it will actually help router and middleware authors to reach higher-quality implementations.

@djui
Copy link
Author

djui commented May 25, 2017

While writing, I got reminded of a website that has a similar comparison, but i can't figure out its address; something related to https://gomiddlewares.org or https://gohttphandlers.org ... which focused only on generic interface support.

@felixge
Copy link
Owner

felixge commented May 29, 2017

That's a great idea. I was thinking about writing a blog post about this library, and perhaps a comparison with other projects attempting to solve this problem would be interesting.

That being said, I think other middleware implementors would probably benefit from simply using this library as it should already cover all use cases. But if they want to duplicate the effort I won't stop them, but they better get all the details right ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants