Several frameworks of commonly used PythonWeb

Analysis of several commonly used PythonWeb frameworks in a variety of language platforms, the emergence of python web frameworks is probably the most, is a hundred flowers in the world, a variety of micro-framework, framework cannot win; the reason for conjecture should be that the framework in python is very simple and the wheel is constantly invented. Institute

In the Python community, there is always a topic about the advantages and disadvantages of the Python framework. The following describes several python frameworks:

Django

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

Django is in a big and comprehensive direction. it is most famous for its fully automated management background: it only needs to use ORM for simple object definition, it can automatically generate the database structure and the full-featured Management backend.

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

Applications must use Django's built-in ORM. Otherwise, they will not be able to enjoy the various ORM-based conveniences provided by the framework. In theory, they can switch out their ORM modules, however, this is equivalent to removing and redecorating the renovated house. it would be better to go to the rough room from the very beginning.

Brand new decoration.

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

The disadvantage of Django mainly comes from Django's insistence on making all its own wheels, and the entire system is relatively closed. The most criticized parts of Django are:

· The system is tightly coupled. if you think that a built-in function of Django is not very good, it is very difficult to replace it with a third-party library you like, such as the ORM and Template mentioned below. It is almost impossible to use SQLAlchemy or Mako in Django, even if

Some patches will make you feel very awkward.

· Django's built-in ORM is far less powerful than SQLAlchemy. apart from Django's three-acre land, SQLAlchemy is the de facto ORM standard in the Python world. Other frameworks support SQLAlchemy, django only sticks to its own set. Django's

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

· The Template function is weak and cannot insert Python code. to write complicated logic, you must use Python to implement Tag or Filter. Django's template system design is very interesting. It should also be the most influential and controversial part in its framework.

The design philosophy of Django templates is to completely separate code and styles. asp.net advocates code/templates separation, but it can still be technically mixed; django fundamentally eliminates the possibility of encoding and processing data in the template.

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

<%

Int I;

For (I = 0; I <10; I ++ ){

....

}

%>

Django does not support embedding code similar to the above. it can only use built-in functions of its template. In fact, it constructs a "new language" for its template "; because the new language is very simple, it can also be transplanted to different platforms.

In most cases, Django's template functions are sufficient, but for special cases (sometimes "special" is not very special), you still need to embed code in the template, then, you need to scale the template according to the rules of the template system. Sometimes, write directly in the template

A single line of code can solve the problem. after the implementation is extended using the template, it will become more than a dozen lines of code.

Whether to tolerate programming in templates is the biggest controversy among Django templates.

Pylons & TurboGears & repoze. bfg

In addition to Django, the other big data is Pylons, because TurboGears2.x is based on Pylons, and repoze. bfg has also been incorporated into this big project in the Pylons project. we will not discuss TurboGears and repoze separately later. bfg.

Pylons and Django have different design concepts. Pylons 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 an optional solution.

By selecting Template, ORM, form, auth and other components, the system is highly customizable. We often say that Python is a glue language, so we can say that Pylons is a glue framework designed by the glue language.

The choice of Pylons is mostly about freedom. the choice of freedom also indicates that you have chosen a nightmare:

· Learning from the nightmare, Pylons depends on many third-party libraries, which are not made by Pylons. You still have to learn how to use these libraries when learning Pylons. sometimes you do not know what you want to learn. The learning curve of Pylons is much higher than that of Django.

The previous 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 hailed as a Python framework suitable for Masters.

· Debugging nightmare. because many modules are involved, once an error occurs, it is difficult to locate the problem. It may be because the program you wrote is wrong, or Pylons is wrong, or SQLAlchemy is wrong. if it is not, the formencode has a bug.

Messy. This problem can be solved only when you are familiar with it.

· A nightmare of upgrading. to install Pylons, nearly 20 Python modules are required. Each module has its own version number. to upgrade the Pylons version, any module with incompatibility problems may occur, upgrading is basically difficult. So far, the Pylons of reddit remains

SQLAlchemy is 0.5.3 in antique 0.9.6, which should be related to this article.

The integration of Pylons and repoze. bfg may lead to the next framework that can challenge Django's position.

Tornado & web. py

Tornado (http://www.tornadoweb.org) is Facebook's open-source framework, and its philosophy is almost two extremes with Django. Tornado is a Web server (not described in this article) and a micro-framework similar to web. py.

Tornado follows a few but refined directions. It also provides the template function. although not encouraged, the author can allow a small amount of encoding in the template (directly embed a single line of py code.

If Tornado is similar to asp.net, it only implements AsyncHttpHandler. In addition, all of them need to be implemented by themselves.

Well, in fact, it has templates, international support, and even the built-in OAuth/OpenID module to facilitate third-party login. In fact, it also directly implements the Http server.

However, it does not have an ORM (only a simple mysql package) or even no Session support, let alone an automated background like Django.

Suppose it is a large website. with high performance requirements, each part of the framework often needs to be customized, and there are very few modules that can be reused. a website developed with Django, various parts are constantly customized, and the rest of the Django framework is probably tornado 1.

Start to provide this part.

The same way.

HTTP server

Tornado directly embeds the HTTP server in order to efficiently implement Comet/backend Asynchronous call to the HTTP interface.

The front-end does not require apache, lighttpd, or nginx to be accessed by browsers. However, it does not fully implement the HTTP 1.1 protocol, therefore, the official documentation recommends that you use nginx at the front end in the production environment, and reverse proxy at the back end to multiple Tornado instances.

Tornado itself is a single-threaded asynchronous network program. by default, it runs multiple instances based on the number of CPUs at startup, taking full advantage of multiple CPU cores.

Single-thread asynchronous

The website basically has database operations, while Tornado is single-threaded, which means that if the database query returns too slowly, the response of the entire server will be blocked.

Database queries are essentially remote network calls. Ideally, these operations are encapsulated as asynchronous operations, but Tornado does not provide any support for these operations.

A system must meet high traffic requirements. it must solve the database query speed problem!

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

Asynchronization and ** no ** essentially refer to the system performance. it only avoids redundant network response waits and switches the CPU consumption of threads.

If the database query response is too slow, you need to solve the database performance problem, rather than calling the front-end Web application of the database.

For queries of data returned in real time, it is ideal to ensure that all data is in the memory, and the database hard disk IO should be 0; such queries can be fast enough; and if the database query is fast enough, therefore, front-end web applications do not need to encapsulate data queries as asynchronous

.

Even with coroutine, asynchronous programs always increase the complexity of synchronization programs. it is worth measuring whether these extra complexities are handled.

If the backend query is too slow to bypass, we recommend that you encapsulate the query in the backend as an HTTP interface and then use the asynchronous HTTP client built in Tornado for calling.