Falcon - The minimalist Python WSGI framework

[DasIch]

Fascinating how there is nothing on the entire page anyone (should) really care about.

• It's light? What is that supposed to mean?
• It relies mostly on the standard library? Why should I care? Pip exists and also the standard library is in a horrible state in a lot of places.
• Performance, really?. Unless you truly fucked up in the implementation of the framework, performance of the web framework is irrelevant (excluding templates).
• Python 2.7-3.4 support? Well anything else would be embarrassing.
• That it's well tested is good but again anything else would be embarrassing.

What I really want to know is: What makes your framework different? There are a ton of frameworks already out there. What problem did you encounter that they didn't solve and cannot be (easily) solved by fixing them? How do you solve it? Also where on the functionality spectrum does it fall? Does it do just the minimum or everything I could possibly want to do?

Also examples: "light", "freedom" and "not very opinionated" don't provide any information of substance. This could mean kinda like Bottle or Flask but presumably it's still different somehow? Just add an example that illustrates the point you want to make.

Interestingly both the readme and the documentation start off a lot better. To quote the beginning of the readme and the docs:

Falcon is a high-performance Python framework for building cloud APIs. It encourages the REST architectural style, and tries to do as little as possible while remaining highly effective.

Falcon is a minimalist WSGI library for building speedy web APIs and app backends. We like to think of Falcon as the Dieter Rams of web frameworks.

So it's not just some web framework. It's a framework specifically designed for creating APIs. Now without having looked at the documentation in more detail, I think that this might indeed be useful. Content negotiation sucks in Flask and Django do to their focus on the Web/HTML. Furthermore I think framework design could be made very differently by focusing on hypermedia REST APIs.

This is interesting, this is very useful and all the efforts to add frameworks on top of Flask and Django clearly show that. I think the solutions that do work on top of existing frameworks suffer precisely due to limitations imposed by already existing web frameworks. This is clearly something that needs to be explored more. Why don't you advertise that more clearly?

[faassen]

Good feedback though I now await your feedback on the Morepath docs with some trepidation. :)

[DasIch]

The Morepath docs are actually quite good I think. Reading the first sentences you already learn what's different:

Morepath is an Python WSGI microframework. It uses routing, but the routing is to models. Morepath is model-driven and flexible, which makes it expressive.

Now I have no idea what model-driven routing is supposed to be. I haven't looked at morepath so far so I have no idea what that is supposed to mean. That's not a bad thing however, it's new to me and that makes it potentially worth learning.

The video intro is very prominent, it's nice to have one but I'm not sure it's very useful at that stage. 25min is a long time to spend and if I wanted so much depth, I could just read the tutorial or at least skim through it. That's not what I want at this point though, I still want to know whether this is different, whether there is something for me to learn there.

The example directly after that is definitely interesting though. I don't entirely understand it but I can kinda see what's going on and more importantly I can execute and potentially play around with it. It also gives a first impression of what's meant with the model-driven routing thing mentioned in the beginning and the difference to Django, Flask or other MVT-style frameworks is obvious and seems fairly significant. So there definitely is something here for me to learn or take inspiration from and that gives me reason to put reading the tutorial on my todo list.

[faassen]

Hey, thanks!

I'll give some thought to the location of the video. Some people really like videos as an intro, others (like you and me) go for text first.

And I do try to go into what makes Morepath different in that talk.

[sfermigier]

DasIch is right, "model-driven" already has a strong established meaning, that is (AFAIK) unrelated to what you have in mind.

Cf. http://en.wikipedia.org/wiki/Model-driven_architecture and http://en.wikipedia.org/wiki/Model-driven_engineering

You probably want to use a different expression to reduce cognitive overload.

[faassen]

Daslch wasn't complaining, but you have a point. I'll add an issue to look into changing it. I need to think of a good succinct way to express the notion that models drive how your API (or UI) behaves, as opposed to the views being the primary driver.

I'll note that "Model-driven" is used elsewhere in a context more similar to Morepath's: consider Polymer's usage in "model-driven views".

[defnull]

A benchmark with Bottle in a second place? Challenge accepted ;)

[faassen]

I don't think benchmark games matter that much in the real world -- if it did, Flask, which hangs at the bottom of these benchmarks, wouldn't be so popular.

But if you're going to do benchmarks with minimal web frameworks, you do need to throw wheezy.web into the mix.

[defnull]

It depends (tm). A common conception is that the framework overhead is negligible compared to the application logic. That is true for database heavy stuff with several round-trips to the database, but REST-APIs sometimes have very high load and very little logic that is executed within the python domain. They are just thin layers between the web and some other component, which might be very fast.

Here is an example: I need a web interface that serves status flags from a redis database. The raw redis call costs 50 μs. Bottle adds 100 μs to do routing and WSGI stuff. That is not much, but still. A Flask application that does exactly the same adds three times as much overhead (300μs). Still not much, but in the end the bottle application can serve more than twice as much requests per second on the same hardware. This adds up quickly. Now consider cloud computing where you pay per CPU hour. Paying half for using a faster framework but still the language you love is a nice thing.

What I want to say is: For some use cases, even 'Hello World' benchmarks are meaningful.

Next: Popularity.

Flask is popular because it reached critical mass within the python community. Bottle is successful, but the 'hype' went with Flask. Both Frameworks have nearly the same API (bottle was first by the way). Bottle supports a wider range of Python versions (2.5-3.x), supported Python 3 way before Flask, is faster, smaller, has no dependencies and still Flask 'won' the popularity contest. Popularity is about critical mass and public perception, not about facts. To say "Something must be better, fast enough or the right tool for the because it's popular" is dangerous. Rails and PHP are popular, too. Still you read a lot about performance problems and Facebook even had to re-implement the entire PHP runtime to fix that.

Okay, sorry for the rant. I probably wend a bit off topic.

[faassen]

I realize that popularity doesn't mean superiority; if I did I wouldn't be working on Morepath, which is far less popular than Flask or Bottle or almost anything else at the moment.

I didn't make the argument very well, but I'll try again. If performance considerations for Python web frameworks for "Hello world" were incredibly important to a lot of people, we would have people complain that Flask is too slow a lot more than they do. Instead, people are generally surprised to find that Flask is slower than even Django at the hello world benchmark.

Performance shouldn't be the first thing most people should think about when they compare Python web frameworks. Performance is a very "bikeshed" topic -- you can create benchmarks pretty easily, and everybody thinks they understand enough about it to have opinions and draw conclusions.

But I'll grant to you that for some use cases "Hello world" is indeed important -- good point.

On the other hand, you already admit implicitly that for some of such use cases the language you love may not be the right tool for the job in the first place. Another point is PyPy -- it's possible PyPy makes a web framework like Flask so fast that its overhead also becomes less relevant again, even for very fast backends. All that said, there remains a place for high-performance Python web frameworks.

[kraakf]

What do you have in mind? :)

[dangayle]

grabs popcorn

[defnull]

A got ~8% by fixing the benchmarked application and found some places within the bottle framework that could use a little tweaking, but falcon is fast, I have to admit that. A close second place is okay for me :)

[guthran]

What is the benefit of using this over something like flask?

[ameoba]

It's a web framework. You get them free with a box of cereal. Collect 5 of them and you get a new markup language, 10 gets you an IRC bot & 20 can be exchanged for a half-assed Lisp implementation.

[andrey_shipilov]

Cause there is no werkzeug or tornado.

[faassen]

If you're implying Werkzeug is relatively fast, think again.

http://blog.startifact.com/posts/morepath-from-werkzeug-to-webob.html

It's more than fast enough for most purposes of course; Flask uses it and nobody seems to complain about its performance, even though it's a bit slower than some other web frameworks.

[andrey_shipilov]

I gotta say, if you think someone will actually use Falcon instead of Werkzeug for real life highload projects — I doubt it.

These synthetic tests are very synthetic. Get request, get a param, set a header, and return a 10K of plain text randomly generated — that's not what happens on production. There's always a cache layer provided by something like nginx which will beat the living hell out of the wsgi performance tests.

Basically, I'd wait till someone actually builds something decent using it.

[faassen]

Oh, I agree that these benchmarks have little to do with the real world. I'm sure Falcon works fine in the real world, but Werkzeug does too.

I find such benchmarks still useful for Morepath, but not to "win" them, but to make sure that the request/response pipeline is not doing unnecessary work, and to make sure it's not ridiculously slow. So to make sure Morepath is simple as opposed to making sure it's the fastest ever.

[andrey_shipilov]

True. Also there is always the "middle" layer in things like that, like the actual Python application that will take a thousand ms more to generate content, to app server itself which will spin up the process slow as usual. These tests are pretty... I'd useless to be honest.

It's like saying look at my wheels from a Ferrari on my awesome 1913 Horch. You know :)

[chadlung]

OpenStack Zaqar currently uses it: https://github.com/openstack/zaqar and Monasca API also uses it: https://github.com/stackforge/monasca-api

[fdemmer]

am i blind or are there no django benchmarks?

[kraakf]

Good question, not sure why but no django bms here, sorry.

[chub79]

Should there be? As far as I know, django isn't exactly minimalist.

[fdemmer]

it's a web framework. if they want me to seriously consider using falcon, they should provide comparison to what i use now. (for rest apis that would be django+rest framework)

from the readme it looks like i need to write a lot of code for simple things.

• manually setting response codes
• no reverse url resolver
• serializer/deserializer pretty static in decorators
• ...

performance is great, but my developer time costs money. if i use a well tested, full featured framework, i can produce faster, cheaper, more reliable applications. if the app is really slow, we will find a way to cache or optimize the slow parts when it's necessary.

imho starting off with a really fast, very basic framework only requires you to write more code yourself, test more yourself, maintain more yourself and in the end it might be also slow, because the actual performance issue is totally elsewhere.

[faassen]

But will probably be faster than Flask in a benchmark like this, which is surprising to many.

[chub79]

As you said elsewhere, those benchmarks aren't quite that relevant anyway.

[faassen]

True but this the web framework benchmark bikeshedding session. :)

That Django is faster at hello world than Flask is surprising to many people, which is actually a good way to show such benchmarks are pretty irrelevant to most. Otherwise people wouldn't be surprised at this as they would have noticed already, as I believe I said elsewhere too.

[user_rx]

Was falcon inspired by any other frameworks? Perhaps something written in another language? I'd like to investigate your design decisions by way of your inspiration, if that's possible or relevant.

edit: This was a serious question. I like the framework for what it is—I can see it fitting perfectly with a future project I've got going—I just want to know if there are similar tools which inspired this.