Possible to use a different router?

If I had 20 million thoughts come to mind changing the router in laravel would not even be included. It would probably be a good idea to forget you ever thought about such a thing.

It would probably be a good idea to forget you ever thought about such a thing.

Using FastRoute was listed as one of the main things that makes Lumen faster than Laravel. If Laravel could use FastRoute it would increase performance. I think the bigger question that I've been thinking about is, would we still need Lumen if Laravel could be made configurable enough to become Lumen. For example, if you could swap in FastRoute, turn off all the service providers you don't need, turn off sessions, etc. then you could possibly make Laravel as fast as Lumen.

Don't mean nothing bad by this but I really think you are way over thinking this stuff. Unless you are planning a large site like FedEx or CH Robinson trucking company I believe the routing Taylor implemented seems to work for most people. And Taylor seems to be a pretty smart person at implementing this stuff.

I agree that the Laravel router works for most people. Taylor is a smart person and it seems like he noticed that Laravel was not fast enough in certain situations such as microservices and that is why he created Lumen and decided to use FastRoute instead of the Laravel/Symfony router. Imagine if you could swap in a different router and get a performance increase. That sounds awesome to me. Which brings me back to my original question if that is possible.

@ejunker Just cache your routes if you’re really worried about performance. But until you’re getting millions of page views a day, any gains from swapping the router is going to be negligible and not worth the immense effort in doing so.

Premature optimization is the root of all evil.

http://c2.com/cgi/wiki?PrematureOptimization

@martinbean yeah I would say Laravel out of the box setup it's going to be fine for most small to medium sites, if you're programming for FedEx I'm sure they have their own little tricks and techniques that use. You gave a real good answer.

@jlrdw @martinbean thank you for your responses but neither of you answered my question. For my own curiosity I'm asking if anybody has done it and how feasible it would be to use a different router. I'm hopeful that since there are some routing contracts/interfaces that it could be done.

On a sidenote, I'm surprised that both of you don't seem to care about performance. I'm excited that PHP 7 provides big performance increases. I don't think you would consider using PHP 7 "premature optimization". The same would be true for a faster Laravel.

@ejunker When did I say I didn’t care about performance? I do care about performance, but other things can be done before swapping core framework components out. Have you thoroughly analysed your codebase and detected Laravel’s router as a performance bottleneck? Or are you just positing based on a hunch? And if you were to spend the time to swap out Laravel’s router, what performance increases are you expecting to see? Because my educated guess is, it wouldn’t be anything near the amount of effort to integrate an alternative router.

Yes, it’s possible. Anything’s possible. It’s just code. But just because something’s possible doesn’t mean it should be done or will have dramatic performance benefits. You have as much danger as finding the opposite is true, in which case how happy is your boss going to be that you’ve spent all that time to make your application’s performance worse?

@ejunker you could probably have two duplicate sites setup on best shared hosting out there one with PHP 5.6 and another with PHP 7 I doubt you'll notice any significant difference in page loading and going about the normal day-to-day database edits and such. Again I just believe you are way over thinking this stuff.

@martinbean good point, I really should run my app through a profiler to see where the bottlenecks are. But this really isn't about my app or any specific app. If somebody were to implement a faster router then everybody would benefit. The thing with routing is I assume as you add more routes that it will get slower. My app currently has 477 routes and we are always adding more as we add new features. Only apps with lots of routes would need to worry about this but I don't know where that threshold is. Taylor used FastRoute for Lumen and added a route:cache command which are 2 pieces of evidence that routing might be a bottleneck. My app recently had to go from 3 to 4 webservers. If we could increase performance enough that we could drop back down to only needing 3 webservers that would be a cost savings.

@jlrdw this is an extreme case but very large PHP sites saw improved overall response time by about 40%

https://mattstauffer.co/blog/laravel-5.0-route-caching

Whether or not you were aware of it, the routing logic in Laravel 4 and earlier--especially as you have more and more routes in your application--were one such place for performance bottlenecks. A site with just a few hundred routes could, in the past, lose up to a half second just for the framework to register those routes.

https://www.reddit.com/r/laravel/comments/2si9rd/how_you_guys_handle_a_tons_of_routes/

Also, Laravel 5 has route caching which Taylor has tested something like 800 routes against, and it matched a request in just a few milliseconds. Route performance is a non-issue for Laravel 5.

So, it appears that routing can be a bottleneck but route caching eliminates the bottleneck.

So, it appears that routing can be a bottleneck but route caching eliminates the bottleneck.

@ejunker Indeed. So cache your results and look for other bottlenecks in your application that can be solved with other quick-wins ;)

Only write new code if you’re certain there’s an issue that will be solved with an alternative/new implementation, and that the benefits far outweigh the time and effort to write said new code, i.e. spending a month to get a 0.1 millisecond improvement probably isn’t worth it.

I’m also not sure what you meant by, “I don't think you would consider using PHP 7 "premature optimization”. Why would I consider using the latest, stable version of PHP premature optimisation? I certainly don’t and would never say anything of the sort. I in fact use PHP 7 for all new projects, and have "php": ">=7.0.0" in the require section of my Composer manifests for Laravel projects.

Thing is with FastRoute (or others) is that you lose functionality. You can't do certain things with it compared to the default.