On 6 February 2014 00:57, franz de leon <[email protected]> wrote: > reading the article, it made me think about routing that it is indeed > pretty costly. what do you think of an adapter in zf2 that would actually > generate .htaccess (mod rewrite) files as a feature? in production this > will work in a caching way to step over the php routing logic. >
Routing is still a feature that the framework should handle. There's a couple of things going on here: - if routing is managed by different files, you end up having multiple application entry points (duplication) - routing is no big performance deal, and DASPRiD is even working on making it faster even if it usually accounts for less than 5% of the page load time - moving routing to files denies custom routes, which is the real power of a router. Routing is not just a pattern matching mechanism, you can plug any logic into a route. People tend to throw "not found" exceptions in controllers - I think that is a mistake. - moving routing out of your application requires your developers to have more knowledge about the environment the application runs in, and reduces portability - moving routing out of your application makes changing routes assembling across your application a nightmare, requiring you to manually change a lot of paths whenever it is happening. So yeah, seems like the usual "squeeze performance out of it" for no big benefit. I had this discussion before with people that highly value performance, and I still think caching is the way to go here, instead of trying to split tasks among different in-homogeneous tools. If your app is THAT application critical for some paths, then you just rewrite your varnish config in order to deal with routing in THAT particular edge case, maybe serving the response from a load balanced tree of machines or a dedicated micro-service built with C or something like that :P Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
