4 ms·

Awesome work! I just watched your PyOhio talk[0], and seems really promising. I use Flask daily, and while performance has not been an issue yet, I know the key

by avyfain 10y ago

Awesome work! I just watched your PyOhio talk[0], and seems really promising. I use Flask daily, and while performance has not been an issue yet, I know the key word in that phrase is yet. Would love to play with the code. Could you add a CONTRIBUTING.md? I could try to figure out how to get started on my own, but having a few pointers would be really helpful. I see there are no issues on GH. What are things you're hoping to add soon/are not implemented yet? [0] https://www.youtube.com/watch?v=vs7XOn1TXVQ https://www.youtube.com/watch?v=vs7XOn1TXVQ

akubera 10y ago
Thanks! The biggest missing piece is simple, well-tested middleware. My focus has been on very general middleware; a kind of 'meta-middleware' that actually spec out a common behavior to minimize surprises and boilerplate. For example, my Renderer & RenderEngine classes[0] don't do anything on their own, but are intended to be used by other, more specific renderers (eg MakoRenderer, JinjaRenderer). I think some common functionality really need to be standardized and not done ad-hoc, as conflicts could arise. (more description on how Renderers work below) The next one of these I'd like to solve is authentication: a standard interface for passwords/oauth/etc. I've kinda used http://passportjs.org http://passportjs.org before, might be a starting point; I don't know what a pythonic version would look like. ## Non-Middleware - Figure out equivalent of JS EventEmitter interface. Currently I have no good way to do something like res.on('send-headers', cb) ~ (thinking res.events['send-headers'].add(cb)) with events as EventManager object. Maybe decorators here? - ETAGs - HTTP/2 - pytest-growler for automated fixtures - I don't think an admin panel is necessary (can't beat django) but would like some CLI tools for site creation, testing, and deployment. Renderer Explaination: (too many 'render' words) The author creates a RenderEngine as the actual middleware: app.use(MakoRenderer("/path/to/view")). All this middleware does is attach a callable Renderer object to res at res.render if it doesn't exist, then add itself to res.render - this allows multiple RenderEngines in the same app (if the author desires) - and none of them will clobber one another. Upon calling the Renderer: res.render('foo', data_obj), the callable scans through the engines until one with 'foo' is found, then the rendered text is sent. It's non-(obvious|trivial) situations like these I want in Growler proper (some batteries included) - the rest can be extensions. [0] https://github.com/pyGrowler/Growler/blob/dev/growler/middleware/renderer.py https://github.com/pyGrowler/Growler/blob/dev/growler/middle...
akubera 10y ago
Also pressing is the method for turning "route strings" (I call them "sinatra paths", I'm not sure where they actually originated) into a regex /foo/{bar} or /foo/:bar => re.compile(r'/foo/(?P<bar>[^/]+)') https://github.com/pyGrowler/Growler/blob/dev/growler/router.py#L128 https://github.com/pyGrowler/Growler/blob/dev/growler/router...

by avyfain 10y ago

akubera 10y ago

Thanks! The biggest missing piece is simple, well-tested middleware. My focus has been on very general middleware; a kind of 'meta-middleware' that actually spec out a common behavior to minimize surprises and boilerplate. For example, my Renderer & RenderEngine classes[0] don't do anything on their own, but are intended to be used by other, more specific renderers (eg MakoRenderer, JinjaRenderer). I think some common functionality really need to be standardized and not done ad-hoc, as conflicts could arise. (more description on how Renderers work below) The next one of these I'd like to solve is authentication: a standard interface for passwords/oauth/etc. I've kinda used http://passportjs.org http://passportjs.org before, might be a starting point; I don't know what a pythonic version would look like. ## Non-Middleware - Figure out equivalent of JS EventEmitter interface. Currently I have no good way to do something like res.on('send-headers', cb) ~ (thinking res.events['send-headers'].add(cb)) with events as EventManager object. Maybe decorators here? - ETAGs - HTTP/2 - pytest-growler for automated fixtures - I don't think an admin panel is necessary (can't beat django) but would like some CLI tools for site creation, testing, and deployment. Renderer Explaination: (too many 'render' words) The author creates a RenderEngine as the actual middleware: app.use(MakoRenderer("/path/to/view")). All this middleware does is attach a callable Renderer object to res at res.render if it doesn't exist, then add itself to res.render - this allows multiple RenderEngines in the same app (if the author desires) - and none of them will clobber one another. Upon calling the Renderer: res.render('foo', data_obj), the callable scans through the engines until one with 'foo' is found, then the rendered text is sent. It's non-(obvious|trivial) situations like these I want in Growler proper (some batteries included) - the rest can be extensions. [0] https://github.com/pyGrowler/Growler/blob/dev/growler/middleware/renderer.py https://github.com/pyGrowler/Growler/blob/dev/growler/middle...

akubera 10y ago

Also pressing is the method for turning "route strings" (I call them "sinatra paths", I'm not sure where they actually originated) into a regex /foo/{bar} or /foo/:bar => re.compile(r'/foo/(?P<bar>[^/]+)') https://github.com/pyGrowler/Growler/blob/dev/growler/router.py#L128 https://github.com/pyGrowler/Growler/blob/dev/growler/router...