I must say, I did a double-take when I saw the front page of HN today.
I get that it follows the theme of Django and Sinatra. But Brubeck is not a very common name (the musician Dave Brubeck is my second cousin) and I don't normally see the musical Brubecks intrude into "my" domain. :)
Amazing! I thought you should know that your second cousin inspired my love of jazz as a child, and Paul Desmond convinced me to pick up the saxophone after hearing Take Five. Thus, jazzychad was born.
OK, now this is interesting. Like twisted or Node.js enabled a new class of web applications, this is offering a lot more than just another Rails/Django clone. I'm happy that there are so many frameworks to choose from based on your personal preferences, but I'm really happy to see a project trying something completely different.
This is the first time j2labs crossed my radar… is this part of a larger project? Anyone in the know want to give the backstory on how this came about?
J2 Labs is the name of my consulting company (and twitter account @j2labs).
Brubeck + DictShield are both projects that have risen from building API's for startups. I aim to make Brubeck as useful as possible for building web projects a quick and easy process, without sacrificing easy scaling.
My thinking here is that a solid model should help developers build their idea fast and make it through the early days of startups without breaking their backs.
I don't particularly like working with Tornado because it offers little support for the plethora of Python drivers that are blocking only. On top of that, the callback model, while powerful, can lead to some seriously confusing code.
I believe people will find the combination of Mongrel2, eventlet and a database agnostic modeling system (DictShield) very flexible.
For some reason my other account is blocked from responding so I created this one.
That is correct about pymongo. Eventlet will convert any drivers that are written entirely in Python into nonblocking driver. Gevent, an alternative to eventlet, can do the same. Brubeck supports both.
In addition to that it also makes ZeroMQ nonblocking. The combination of ZeroMQ support and pymongo, pyredis and pyriak all being available entirely as python (bson is in c tho) is what convinced me I had to write a new framework.
Your account is probably blocking you from responding because of some flamewar prevention feature Paul put in a while ago that makes it difficult for commenters to have nested discussions with one another--the deeper the discussion, the longer you have to wait before making a reply to a user who just replied to you.
You know more about thrift than I do. If the "blocking" code is in python, eventlet should be able to fix it. You can't do anything about the native machine code, though. It appears that the client library includes a c-based codec to improve performance, but it should not be a problem if the transport is based on python sockets.
I use pymongo with gevent. A small hack is necessary to prevent pymongo from making a new connection for each thread that accesses mongodb (because with gevent, you can have a massive number of threads). I'd imagine the same is true with eventlet.
There are so many different web frameworks available for Python now. How would somebody make the choice over Brubeck, Flask, Bottle, web.py, Django, Pylons, etc... I know somebody will probably say something like "use the best tool for the job" but what is best for what job?
edit; That's just Python frameworks. The situation gets even messier when you start to consider every other languages for web development. Lots of 'hip' technologies I would love to put time into learning but I can't learn them all...
Brubeck is a Mongrel2 handler which makes it effectively a ZeroMQ Framework. But it is built with web serving in mind so I (I wrote it) attempted to also bring many of the customs we're used to with web frameworks to the Python + Mongrel2 world.
There are many python frameworks and each serves a different need. If you are a Tornado user but find the blocking / nonblocking paradigm confusing, you would probably get a lot out of Brubeck because it replaces the IOLoop (like Twisted's reactor) with a simpler system, eventlet.
I'm glad you think it's hip! It's only a couple months old.
Agreed. For a newcommer, the question "which framework is most worth my time investment" has has become rather daunting. Seems like the safest choices are the big ones like Rails or Django, but there always seems to be something tempting and fun on the horizon.
"Spending too much Time with the Choice of Framework
This should probably go to the top. If you have a small application (say less than 10.000 lines of code) the framework probably isn't your problem anyways. And if you have more code than that, it's still not that hard to switch systems when you really have to. In fact even switching out core components like an ORM is possible and achievable if you write a little shim and get rid of that step by step. Better spend your time making the system better. The framework choice used to be a lot harder when the systems were incompatible. But this clearly no longer is the case."
That is a goal of Brubeck too. By using DictShield for modeling you get all your modeling needs, including serializing to Python dictionaries or JSON strings, but it doesn't have an opinion on what database you us.
Your database layer might change, for whatever reason, so you adjust a few queries for loading data and you're back in action.
In addition to this many people haphazardly choose their framework and make the mistake of using Tornado without understanding how nonblocking I/O works. If a user chooses.
Brubeck, they would get nonblocking support for free, which makes it a considerably safer haphazard choice.
I think it's unfortunate that the power of choice isn't as appreciated outside the Python world but I can also relate to people who feel they have to read way too much stuff.
In spite of this, however, Brubeck indeed aims to be a one-stop shop. It uses coroutines + nonblocking I/O to make scaling up easy but it also a web.py style routing system because all of us know this style already.
Choice is great for veterans, but for someone learning Python or Ruby, how do they know what to pick? How to they know that they're not going to bet on a losing horse that stops being actively developed after a while and doesn't do anything for their career. Veterans can afford to play around and test out new frameworks, because they can always fall back to Django or whatever pays the bills, but newbies can't.
Also consider that some frameworks (ala Django) go for the 'kitchen sink' approach which is better for newcomers. Others (like Express with NodeJS) just do a few minimal helpers and otherwise get out of the way.
In this case, the plethora of frameworks is an advantage for the advanced developer, while the few big obvious ones stand out for newcomers.
The difference here is that Brubeck answers ZeroMQ messages from Mongrel2 instead of being a web server. So instead of using WSGI, Brubeck connects to Mongrel2 via a ZeroMQ socket and reads messages representing the web requests.
Beyond that I attempted to create a familiar interface for everyone who's used a pythonic web framework before. Indeed, a lot like Flask, but also like Tornado.
Agreed. If you limit your application to WSGI then mongrel2 is "just" another high-performance event-driven webserver. To really take advantage of the advanced features of m2 you need a framework that's more closely tied to its model of the world.
(speaking as author of the m2wsgi module linked above)
I haven't done anything significant with Mongrel2 yet, so my mental model of its operation is probably somewhat flawed, but I was thinking about my above post for a while yesterday.
It seems like WSGI supports a subset of Mongrel2 features. Any "pure" WSGI app can run fine behind Mongrel2, but Mongrel2 allows much more than the WSGI model. For example, a response in Mongrel2 is just a socket getting written to. Mongrel2 can send a request to server A, and then receive the response from a completely seperate server B. Can WSGI support something like this? As far as I know, someone would need to reimplement a lot of Mongrel2's functionality in Python (which is idiotic) just for WSGI compliance.
Again, I've yet to build anything with Mongrel2 and I haven't read the WSGI PEP in a while, so please correct me if I'm wrong about anything. After thinking about it yesterday, I find the differences between a more traditional WSGI-esque model and something like Mongrel2 to be fascinating.
WSGI is fine if you're building short-lived, simple request/response style web apps but if you want to do any sort of async messaging, long-polling, or use websockets i.e. a modern web app - then it leaves a lot to be desired. Mongrel2/Brubeck appear to be designed with these considerations in mind.
Looks very promising. I'm getting the impression that it has a better architecture than Django; I think that if and when it will match Django in level of finish, documentation, community, tools, etc., it might become a serious competitor.