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?
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 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.
could you add a representative example to show how we can use your framework with Postgres ? For example, psycopg vs psycopg2 vs psycogreen vs psycopg2-cffi vs aiopg ... I dont even know which one will work properly using your framework and how (and maintain async characteristics).
(Comment from a bystander). You probably want aiopg in order to maintain the async characteristics and use the "friendly" asyncio syntax.
There is also peewee-async (http://peewee-async.readthedocs.io/en/latest/) if you want an ORM using asyncio. (I've been meaning to try this myself, but haven't had an opportunity).
absolutely.. i am concerned about frameworks not fundamentally thinking about DB. With async, there is that additional problem of "this does not work in async mode". So I would hope the developers include database hookup as part of their unit test suite.
As I understand, the asyncio module was inspired by Twisted.
Growler is, at its heart, a super minimal interface: passing (req, res) pairs through a pipeline of middleware (similar to node).
Since this is built with the standard library, all kinds of features, such as async DB access, will become available as the community builds them; and these may be added to your pipeline super cheap.
I have not used aiohttp, but it looks like their application must be initialized with a list of middleware_factories. I do not see any logic in choosing middleware - just a straight shot.
Growler apps just add functions to an internal list, and these may be 'mounted' on particular end points/http requests.
Also, in aiohttp it is up to your endpoint to create the response object and return it. While in Growler it is created by the application (or rather the GrowlerHttpResponder) and passed around the middleware - getting enhancements (res.render('foo') is not standard) and having callbacks registered (to, say, log ALL headers sent - something you want done only at the time of sending headers).
I think it would be possible (or at least I would like to get to the point) where you could actually mount other apps from other frameworks into a Growler app. So if there is blog software you like written in aiohttp, there is special middleware to transform growler requests into a aiohttp requests.
An initial test last night of a trivial growler app (i.e. one method that replies with a simple string) saw a median response time drop from ~200ms to ~80ms.
Rupy can switch code on the fly, meaning you can have users hitting your server and they will run the old code one request and new code the next. No other system I know of works like this, hot-deploying on a remote machine over HTTP seamlessly. Maybe erlang can do it but then again I can't write a 3D game in that language so Java still has the upper hand for my requirements.
Off the top of my head, if you write a custom MiddlewareChain class that exposed its own management port, you could inspect and modify the state of the chain at any time, checkboxes to disable middleware, change endpoints, insert debug middleware, etc.
I like this... definitely worth thinking about. Thanks, all!
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