A brief analysis of several commonly used Python Web frameworks

Among various language platforms, Python probably has the most web frameworks emerging. It is a world where a hundred flowers bloom, with countless micro-frameworks and frameworks. I guess the reason is that it is very simple to construct a framework in Python, which makes the wheel keep spinning. was invented. So

There are always topics in the Python community about the pros and cons of Python frameworks. Let me introduce you to several major python frameworks:

Django

Django should be the most famous py framework. Google App Engine and even Erlang have frameworks affected by it.

Django is taking a large and comprehensive direction. It is most famous for its fully automated management backend: you only need to use ORM and make simple object definitions, and it can automatically generate database structures and full-featured management. Backstage.

The convenience provided by Django also means that Django’s built-in ORM is highly coupled with other modules in the framework.

The application must use Django’s built-in ORM, otherwise you will not be able to enjoy the various ORM-based conveniences provided in the framework; in theory, you can switch out its ORM module, but this is equivalent to demolishing the decorated house If you want to renovate, it is better to go to the rough room to do a brand new decoration from the beginning.

Django’s selling point is its ultra-high development efficiency, but its performance expansion is limited; projects using Django need to be reconstructed after the traffic reaches a certain scale to meet performance requirements.

The shortcomings of Django are mainly due to Django’s insistence on making all its own wheels. The entire system is relatively closed. The most criticized aspects of Django are:

· The system is tightly coupled. If you feel that a certain function built into Django is not very good Well, it is difficult to replace it with your favorite third-party library, such as ORM and Template as mentioned below. It is almost impossible to use SQLAlchemy or Mako in Django, and even with some patches, it will make you feel very, very awkward.

· The ORM that comes with Django is far less powerful than SQLAlchemy. Except for Django, SQLAlchemy is the de facto ORM standard in the Python world. Other frameworks support SQLAlchemy, but Django still insists on its own. set. Django's

developers have also discussed and tried to support SQLAlchemy, but finally gave up. It is estimated that the cost is too high and it is difficult to integrate with other Django modules.

· The Template function is relatively weak and cannot be inserted into Python code. To write more complex logic, you need to use Python to implement Tag or Filter. The design of Django's template system is very interesting, and it should also be the most influential and controversial part of its framework.

The design philosophy of Django templates is to completely separate code and styles; asp.net advocates separating code/templates, but technically they can still be mixed; while Django fundamentally eliminates coding and processing in templates data possible.

For example, in the asp.net template you can write:

int i;

for(i==0;i

....

}

%>

Django does not support embedding code like the above at all, and can only use the functions built into its templates; this is actually constructing a "new language" for its templates; due to this "new language" It is very simple, so its templates can also be ported to different platforms.

In most cases, Django's template function is sufficient, but for special (sometimes "special" is not very special) situations, you still need to embed code in the template, then you need to follow the rules of its template system Make template extensions. Sometimes, a problem that can be solved by writing

directly in the template with one line of code will become more than a dozen lines of code after being implemented with template extension.

Whether programming in templates is tolerated is the most controversial aspect of Django templates.

Pylons & TurboGears & repoze.bfg

Besides Django, the other big one is Pylons, because TurboGears2.x is based on Pylons, and repoze.bfg has also been incorporated into this large project in the Pylons project Here, TurboGears and repoze.bfg will not be discussed separately later.

The design concepts of Pylons and Django are completely different. Pylons itself only has about two thousand lines of Python code, but it also comes with some third-party modules that are almost used by Pylons. Pylons only provides one shelf and optional solutions. You can freely choose components such as Template, ORM, form, auth and so on according to your own preferences. The system is highly customizable. We often say that Python is a glue language, so we can definitely say that Pylons is a glue framework designed with glue language.

Choosing Pylons is probably choosing its freedom. Choosing freedom also indicates that you have chosen nightmare:

· Learning nightmare, Pylons relies on many third-party libraries, which are not made by Pylons. When you learn Pylons, You still have to learn how to use these libraries. The key is sometimes you don’t know what you want to learn. The learning curve of Pylons is much higher than that of Django, and it

The former official documentation of Pylons has always been the target of criticism. Fortunately, the book The Definitive Guide to Pylons was published later, and this situation has changed. For this reason, Pylons was once known as a Python framework only suitable for experts.

· Debugging nightmare, because there are many modules involved, and once an error occurs, it is difficult to locate the problem. It may be the fault of the program you wrote, or it may be that Pylons is wrong, or SQLAlchemy is wrong, or maybe there is a bug in the formencode. Anyway, it is very messy. This problem can only be solved if you are familiar with it.

· Upgrading nightmare. To install Pylons, you need to install nearly 20 Python modules, large and small, each with its own version number. To upgrade the version of Pylons, it is possible that any module may have incompatibility issues, and upgrading is basically difficult. It's hard. So far, reddit's Pylons is still stuck at the

antique version 0.9.6, and SQLAlchemy is still at version 0.5.3, which should be related to this.

The integration of Pylons and repoze.bfg may give birth to the next framework that can challenge Django's status.

Tornado & web.py

Tornado ( http://www.tornadoweb.org ) is an open source framework from Facebook. Its philosophy is almost the opposite of Django. Tornado is a Web server (this article will not elaborate on this), and it is also a micro-framework similar to web.py.

Tornado is taking the direction of less but more precise. It also provides template function; although it is not encouraged, the author can allow a small amount of coding in the template (directly embed a single line of py code).

If compared with asp.net, Tornado is a bit similar and only implements AsyncHttpHandler; apart from that, you need to implement everything yourself.

Well, in fact, it has templates, international support, and even a built-in OAuth/OpenID module to facilitate third-party login. It actually directly implements the HTTP server.

But it doesn’t have an ORM (only a super simple encapsulation of mysql), and it doesn’t even have Session support, let alone an automated backend like Django.

Assume it is a large website. Under the requirement of high performance, each part of the framework often needs to be customized, and there are very few modules that can be reused. For a website developed with Django, each part has been continuously customized, and the Django framework The rest is most likely what tornado can provide from the beginning.

Different paths lead to the same destination.

HTTP server

In order to efficiently implement the Comet/backend asynchronous call to the HTTP interface, Tornado directly embeds the HTTP server.

The front-end can be accessed by the browser without adding apache/lighttpd/nginx, etc.; however, it does not fully implement the HTTP 1.1 protocol, so the official document recommends users to use nginx on the front-end in a production environment, and reverse the back-end Proxy to multiple Tornado instances.

Tornado itself is a single-threaded asynchronous network program. When it is started by default, it will run multiple instances according to the number of CPUs; taking full advantage of the multi-core CPU.

Single-threaded asynchronous

Websites basically have database operations, and Tornado is single-threaded, which means that if the database query returns too slowly, the entire server response will be blocked.

Database queries are essentially remote network calls; ideally, these operations would be encapsulated as asynchronous; but Tornado does not provide any support for this.

For a system to meet high traffic, it is necessary to solve the problem of database query speed!

If there is a query performance problem in the database, no matter how the entire system is optimized, the database will be a bottleneck and slow down the entire system!

Asynchronous does not **essentially** improve the performance of the system; it just avoids unnecessary waiting for network responses and the CPU consumption of switching threads.

If the database query response is too slow, what needs to be solved is the performance problem of the database; not the front-end web application that calls the database.

For real-time returned data query, ideally it is necessary to ensure that all data is in memory, and the database hard disk IO should be 0; such a query can be fast enough; and if the database query is fast enough, then the front-end web application will also There is no need to encapsulate data queries as asynchronous

.

Even if you use coroutines, asynchronous programs will always increase the complexity of synchronous programs; what needs to be measured is whether dealing with these additional complexities is worth it.

If there are queries on the backend that are too slow and cannot be bypassed, Tornaod’s suggestion is to encapsulate these queries independently in the backend into HTTP interfaces, and then use Tornado’s built-in asynchronous HTTP client to make calls.