flask-classy
flask-classy copied to clipboard
apiguy
Add support for Lazy Views
[email protected] recommended adding support for Lazy Views, which is useful for apps where initial load times are super important. I agree, as situations like GAE and Heroku can be impacted by long initial imports.
What's a first step for this? Flask-classy looks super-cool and I like evaluating tools by getting to know them through fixing bugs fist. And I really like doing stuff lazily.
Basically a more sophisticated routing system is needed. Right now, when you register a FlaskView all the routes are registered with the app (or blueprint) instance at that time. In order to make it lazy Flask-Classy needs it's own router that chooses the view at runtime.
In order to do that though, we need to get Flask to defer to us for the routes we care about. The natural seeming way would be to have a "catch-all" route that we register with Flask that routes to our internal router. While I'm not sure what the performance penalty would be for this, I'm more concerned that I couldn't guarantee that I wouldn't be clobbering a route from another view (non Flask-Classy) that is added after the Flask-Classy views are registered.
Another possible solution would be to modify the app instance during registration so that it uses a custom, or at least wrapped routing mechanism to give Flask-Classy the chance to respond to any routes it's managing and then allows the original app router to continue as expected. The tricky part with this comes when dealing with Blueprints which don't actually have a built in router for us to override and instead they add their routes to the global routes upon registration with the app.
Ideally Flask would have the ability to allow me to register my own route handler (as a plugin) and that would solve it nicely as it would mean the second solution would be possible without mokey-patching the app instance. I'm not sure how @mitsuhiko feels about that, but maybe with a good enough use case we could convince him or @kennethreitz that it's worth having.
I agree this sounds much higher up in the call stack above classy and a little bit out of scope, even if it would be an awesome feature. It's somewhat priority that interoperability with the default flask routing methods be maintained.
