FastRoute
FastRoute copied to clipboard
nikic
Looking for maintainer / Version 2.0
Back when I wrote this library, it was intended as a small experiment in efficient routing. I certainly did not expect it to be as widely adopted as it was. The functionality and interfaces offered by this library are not enough for many use-cases. I think three common pain points are:
- The weird dispatch return value, which is an ad-hoc variable length array. See also #171.
- The lack of support for reverse routing / reconstructing a URL from parameters. See also #66, #139.
- Caching being somewhat hard to use, in part because closures are not directly supported (#141). Because of this FastRoute is often used without caching, in which case it certainly is very far from fast (#140).
I think it is time to release a version 2.0 of this library, which addresses these and other issues by performing the necessary (backwards-incompatible) API changes.
However, I don't have the time, motivation and expertise to do this myself -- I'm not writing a lot of web-facing code nowadays and am probably not the best person to work on this type of library.
As such, I'm looking for a new maintainer for this library and in particular someone who is interested in bringing out an overhauled major version. Please comment if you're interested :)
Here at Apidemia we are interested in this one . We are actively developing and using on a daily basis for past year or so an PSR-7 Middleware application @https://github.com/dotkernel, based on Zend Expressive 3. The routing package we are using is hardcoded to fast-route, so its not only an option like in Zend Expressive. We are several guys here which can contribute, maintain, test, develop a version 2.0 As we are completed commited to PHP, Zend and Middlewares.
Also almost all of us are ZCE's
What about directing ppl at symfony/routing >=4.1? It has all missing features + its faster already (thanks to you!) If anything is missing from the package, we would happily accept suggestions!
@nicolas-grekas, symfony/routing looks quite complex. As do many Symfony components. Even with all the missing or rough parts of FastRoute, I prefer it for smaller projects.
@XedinUnknown I'm not sure the component has much unneeded complexity. For sure it handles more features than FastRoute v1. But this issue is basically about growing the feature set, thus adding complexity also. Also I don't wish anyone else to duplicate the effort that we put into the code to make it the fastest PHP router out there... so that sharing this effort might be better than having someone spend their free time on that... Of course as said in my first message, if one would like to propose some improvements to make the component better somehow, that'd be useful to everyone.
@nicolas-grekas although I understand your effort to have less "duplicated" tools in the ecosystem to allow people to focus, I'd say that it seems that FastRoute has users that don't plan to migrate to symfony/routing (TBQH I'm one of them - at least for now).
With that said I'd suggest us to keep the discussion on "call for maintainers" instead of "let's all use symfony/routing". We can discuss the reasons why people don't wan't to migrate in another place.
I would be happy to take on the work towards the overhauled version, and subsequent maintenance of Fast-Route.
I have been using it for a few years now and am dedicated to continue using and improve it. As a regular on SO php chat, I believe I am in a position to ask the needs of a large and diverse group of people in regard to moving forward.
I think Fast-Route has its own place in the routing ecosystem, and would see it evolve in parallel with other initiatives.
Maybe people from https://github.com/thephpleague/route would be interested, i think they are one of the most installed dependents of this project.
I think this all depends what you want it to become @nikic , you solved a problem here that many of us have very much appreciated. The feature set for routing imo needs nothing added, dispatching is a little different but also per use case, hence my additions in league/route, the additions in slim, etc. If your goal is for it to stay focused on routing, you’ve done that, just freeze the features, or make them a little friendlier and maintain that. Otherwise if you want it to grow further I’d certainly be interested in chatting with you about what your vision for it is and whether I’d be suited for taking the reigns, whether that be folding it in to league/route somehow or something else entirely.
Hi @nikic,
we're using FastRoute in @flarum and like it very much - thanks for the awesome project! That said, we would also like to see it maintained and would like to offer any help we can provide. We already built our own abstraction around URL generation, and would be happy to work on API improvements as well. :)
Have a great day!
Would be nice if we can create a community around this library then all of Us can work on improvements and new features also build some other tools for routing and dispatching for example. my vote is for community.
IMO this is Github, and therefore already a community. Anybody can contribute to OSS projects here. This thread is about who the maintainers will be.
@XedinUnknown you're right, I meant "organization" then the library does not be owned by on single person
I think any project needs to be owned by a single person, but have multiple maintainers.
I can help doing somewhat in this Project.. Using this in my newly created app and i like this alot... Would also appreciata a function to determine a route by a accept-header :)
@SeaLife, that's an interesting idea. I would make a separate issue for this, if I were you. Also, there can be multiple ways to determine a route, so if I was to standardize this behind an interface, I would consider accepting a RequestInterface, and returning a route.
@nikic I'd like to see this project to not die. FastRoute is simple, easy to use and efficient routing solution if you don't want complex functionality. It works great with PHP-DI, so I absolute love it. Especially the purity in dependencies.
Sorry for the delay here, this dropped off my radar. I have now added @lcobucci as a maintainer to this repo, so hopefully he can get the effort towards version 2.0 going :)
A first step would probably be to bump the PHP version requirement to something more recent than the last ice age, such as PHP 7.1...
FastRoute runs perfectly on PHP 7.2 which I use for my current project, so it could be safely bumped. 😄
@hron84 I'm slightly more strict in terms of supported versions and would bump it to 7.3 directly but we can go slow here :joy:
@lcobucci I'd prefer to see support 5.6 even if it's EOL since there is a lot of hostings that only supports this by default but make 7.2 as a recommended platform. As a sysadmin/devops I see a lot of small companies trapped by this PHP 5 EOL, provider does not/can not upgrade, company can't move because prices and/or contracts. While I understand why most opensource project switch to stop supporting EOL'd platforms, not-so-much projects should no do this - if there is a way. If it's not possible... that's an another topic.
Instead of bumping min requirement of PHP, it makes more sense IMHO to simply test against the new version. But this is already happening, from 7.1 to nightly of 7.4. So there's no reason to do anything more in that regard, I think. Why drop support if there's no effort to continue? Or are you planning to use some new PHP feature? Maybe this is what should be decided first? In this case, even if support for some PHP versions needs to be dropped, this should probably be the last thing to do.
Instead of bumping min requirement of PHP, it makes more sense IMHO to simply test against the new version. But this is already happening, from 7.1 to nightly of 7.4. So there's no reason to do anything more in that regard, I think. Why drop support if there's no effort to continue? Or are you planning to use some new PHP feature? Maybe this is what should be decided first? In this case, even if support for some PHP versions needs to be dropped, this should probably be the last thing to do.
@XedinUnknown bumping to latest stable version is what I do with my libraries. No plans to do this for FastRoute v2.0 (which is what I meant with "go slow here").
7.1 was what @nikic wanted and we can bump it up for newer releases if we plan to either change our vision in FastRoute or decide to use more modern features. But it shall be discussed in the future (in a separated thread IMO).
@lcobucci I'd prefer to see support 5.6 even if it's EOL since there is a lot of hostings that only supports this by default but make 7.2 as a recommended platform. As a sysadmin/devops I see a lot of small companies trapped by this PHP 5 EOL, provider does not/can not upgrade, company can't move because prices and/or contracts. While I understand why most opensource project switch to stop supporting EOL'd platforms, not-so-much projects should no do this - if there is a way. If it's not possible... that's an another topic.
@hron84 v2 will require PHP 7.1+ (v2-dev already requires it). However, that doesn't prevent us to define our policy regarding what gets backported to v1. I think this is still open. My personal opinion is that security and critical fixes should be backported but not new features. Let's take to a separate thread too :+1:
Happy to see there is a new maintainer. Is there a roadmap with the list of futur features for the v2 ? or not yet ?
@lcobucci No need for separate thread, I absolute love the direction you facing to.
Laravel's sister framework, "Lumen" is currently using fastroute ^1.3, and needs to decide what to do in the future. Will there be a fastroute 2.0, or will a replacement package be recommended instead, such as Symfony's router.
// cc @driesvints
@GrahamCampbell As I currently see, nothing prevents Laravel to co-maintain FastRoute. Maybe together with Apidemia by @arhimede and @lcobucci?
I'm not sure laravel wants to take on maintaining a router, which was the reason for choosing an external routing package. I don't speak on behalf of @taylorotwell though. Maybe I am wrong. :)
This is why I recommended co-maintaining. It could help to reduce the maintenance work if two team can work on it.
@lcobucci so is your life still busy after 8 month since your last comment? 😃
@burzum it got even crazier recently... but am almost getting back in track :crossed_fingers:
@lcobucci I wouldn't mind to contribute, for example in a PR that implements a proper return value instead of the array from the dispatcher. But I would like to discuss this with whoever is in charge to not waste my time on something that is already done or somebody wants to do different than I have in mind. Please see https://github.com/nikic/FastRoute/issues/171#issuecomment-662722861
@lcobucci no answer on this yet? Also almost no commit in 2020 and there is a LOT open PRs. I'm sorry but I don't have the impression that anything is maintained here. 😞 I don't want to be the maintainer of this project either but I wouldn't mind to contribute but it's hard if nobody replies and PRs are ignored.
@nikic it might be a good idea to pick a second or simply another more pro-active maintainer.
@burzum I'm terribly sorry you feel this way. Your contribution is always helpful but bear in mind that I'm also trying to get a better perspective of the overall direction of the library.
Having more people onboard is great anyway, I really don't want to be the cause of someone's frustrations.
@lcobucci my contribution will be only helpful if the PR gets accepted and my time not wasted. So I need a person in charge that I can talk to and get some discussion started instead of silence and PRs not being handled since month.
I would like to implement what is discussed here https://github.com/nikic/FastRoute/issues/171#issuecomment-662722861 but need some feedback of the maintainer if the proposal is OK.
Also I'm sure other people would contribute more if they would get some kind of feedback on their issues and PRs. There are PRs going back to 2018 that aren't disussed so people can make progress or at least rejected with a good reason and closed.
This https://github.com/nikic/FastRoute/pull/213 for example is a good PR, I would just change what I proposed in the comments https://github.com/nikic/FastRoute/pull/213#issuecomment-648650675 and it would be ready to go.
I thought I could use FastRoute for my next project, but this discussion makes me feel disappointed. I see that @burzum invested a lot of time, so I could use his fork instead, but I'd prefer to use code that is "officially maintained". So what do you recommend to people like me? Just look for a different solution? (I am not going to use any Symfony component, sorry.)
To everyone complaining about the state of maintenance here: this is open source. You're free to fork the project and maintain the fork which the license allows for. Stop pressurising maintainers.
I did not intend to put pressure on anyone. It's just a pity that such a sophisticated solution goes down, even though there were many offers to take over further care. Those who come here are faced with the question of what to do if they are interested in using FastRoute for their own projects. Not everyone is able to take care of further maintenance on their own.
Well, obviously it is better to look for another solution, so my question is answered. Thanks for that.
That being said, Fast Route was created as an experiment in efficient routing. In order, to make it useful in real application you'll have to create a non-trivial adapter or abstration layer around it. Example from Slim framework. After this your application router wouldn't be much faster than any other PHP router. Another point here, routing is not really a bottle neck in real web applications. From my experience, most of web sites have 20-80 routes. For these projects the routing algorithm is much less important than usage convenience and maintanability. Even in a project with 100+ routes, routing will hardly cause any performance issues.
I suppose, people choose Fast Router mainly because of its simplicity. Symfony Router is quite fast and more powerfull, but it is a bit compicated. It has soft depenedencies on a few other Symfony components and tries to cover use cases that many sites will not ever face. And besides, it has no support for PSR-7 yet.
After quite a long hesitation about choosing a router for the next project I had to create a new router which, I hope, addresses the above mentioned issues.
Thank you Ivan! Good statement!
I will have a closer look at your implementation.