|
| 1 | +# pyEchoNext / web frameworks device |
| 2 | + |
| 3 | +--- |
| 4 | + |
| 5 | +The most important parts of web frameworks are: |
| 6 | + |
| 7 | ++ Routing handlers: |
| 8 | +- Simple: `/index` |
| 9 | +- Parameterized: `/article/{article_id}` |
| 10 | ++ Request handlers (views, handlers). |
| 11 | + |
| 12 | +Basic requirement: the web framework must be supported by a fast, lightweight and efficient server (eg gunicorn). Python has a WSGI guide for this. |
| 13 | + |
| 14 | +## Web server design in Python |
| 15 | + |
| 16 | +``` |
| 17 | +REQUEST |
| 18 | +CLIENT <--------------> [HTTP (80) or HTTPS (443)] Server |
| 19 | +ANSWER |
| 20 | +
|
| 21 | +> Application with logic |
| 22 | +> Data conversion for a python application <-- Area of interest for the web framework (ensuring gunicorn works with it) |
| 23 | +> Gunicorn |
| 24 | +> Converted data |
| 25 | +SERVER -> NGINX |
| 26 | +> Data routing |
| 27 | +``` |
| 28 | + |
| 29 | +When developing a web application in python, we encounter the following problems: |
| 30 | + |
| 31 | ++ Many frameworks (ex. django) do not know how to route response requests. |
| 32 | ++ Applications are insecure and may be susceptible to DDoS (Distributed Denial of Service) attacks. |
| 33 | ++ No load balancing between multiple servers. |
| 34 | ++ NGINX solves the problem of load balancing, but it cannot run and communicate with Python applications. |
| 35 | + |
| 36 | +Therefore, there is a need to use a WSGI server (Web Server Gateway Interface) and a proxy server (such as NGINX). |
| 37 | + |
| 38 | +## WSGI |
| 39 | +Python currently boasts a wide range of web application frameworks such as Zope, Quixote, Webware, SkunkWeb, PSO and Twisted Web, just to name a few. This wide variety of options can be a challenge for new Python users, as typically their choice of web framework will limit their choice of web servers to use, and vice versa. |
| 40 | + |
| 41 | +In contrast, although Java has as many web application frameworks available, Java's "servlet" API allows applications written with any Java web application framework to run on any web server that supports the servlet API. |
| 42 | + |
| 43 | +The availability and widespread use of such APIs in web servers for Python—whether those servers are written in Python (e.g., Medusa), built-in Python (e.g., mod_python), or call Python through a gateway protocol (e.g., CGI, FastCGI, and etc.) - will separate framework selection from web server selection, allowing users to choose the pair that suits them, while freeing up framework and server developers to focus on their preferred area specializations. |
| 44 | + |
| 45 | +Thus, this PEP offers a simple and universal interface between web servers and web applications or frameworks: the Python Web Server Gateway Interface (WSGI). |
| 46 | + |
| 47 | +But the mere existence of the WSGI specification does nothing to address the current state of Python web application servers and frameworks. Authors and maintainers of servers and frameworks must actually implement WSGI for it to have any effect. |
| 48 | + |
| 49 | +However, since no existing server or framework supports WSGI, an author who implements WSGI support will not receive immediate rewards. Thus, WSGI must be easy to implement so that the author's initial investment in the interface can be fairly low. |
| 50 | + |
| 51 | +Thus, ease of implementation on both the server side and the interface framework side is absolutely critical to the usefulness of a WSGI interface and is therefore a primary criterion for any design decisions. |
| 52 | + |
| 53 | +However, it should be noted that ease of implementation for a framework author is not the same as ease of use for a web application author. WSGI provides a completely "no frills" interface for the framework author, because bells and whistles like response objects and cookie handling would simply prevent existing frameworks from solving these problems. Again, the goal of WSGI is to facilitate simple interoperability between existing servers and applications or frameworks, not to create a new web framework. |
| 54 | + |
| 55 | +It should also be noted that this target does not allow WSGI to require anything that is not already available in deployed versions of Python. Therefore, new standard library modules are not proposed or required by this specification, and nothing in WSGI requires a Python version greater than 2.2.2. (It would be nice, however, for future versions of Python to include support for this interface in the web servers provided by the standard library.) |
| 56 | + |
| 57 | +In addition to being easy to implement for existing and future frameworks and servers, it should also be easy to create request preprocessors, response postprocessors, and other WSGI-based "middleware" components that look like an application to its containing server, while also acting as a server to its contained applications. If middleware can be both simple and reliable, and WSGI is widely available in servers and frameworks, this allows for the possibility of an entirely new type of Python web application framework: one consisting of loosely coupled WSGI middleware components. Indeed, existing framework authors may even choose to refactor their frameworks' existing services so that they are exposed in a way that becomes more like the libraries used with WSGI and less like monolithic frameworks. This would then allow application developers to select "best-of-breed" components for a specific functionality, rather than committing to all the pros and cons of a single framework. |
| 58 | + |
| 59 | +Of course, as of this writing, that day is undoubtedly quite far away. At the same time, this is a sufficient short-term goal for WSGI to enable the use of any framework with any server. |
| 60 | + |
| 61 | +Finally, it should be mentioned that the current version of WSGI does not prescribe any specific mechanism for "deploying" an application for use with a web server or server gateway. Currently, this is necessarily determined by the server or gateway implementation. Once enough servers and frameworks have implemented WSGI to provide hands-on experience with various deployment requirements, it may make sense to create another PEP describing |
| 62 | + |
| 63 | +## Integer pyEchoNext |
| 64 | +pyEchoNext is a universal tool with the ability to make a monolithic web application, or vice versa, a modular web application. Django was too big and clumsy for us, flask or fastapi was too small. Therefore, we decided to take some features from django and flask/fastapi, combine them and make it all symbiotic. So that you can make a large monolithic project or a small service. And to turn a small service into a large application or vice versa, a minimum of effort was required. |
| 65 | + |
| 66 | +Our goals were also to make all this as clear as possible, developer-friendly, and add the ability to integrate third-party libraries. |
| 67 | + |
| 68 | +As a result, the main characteristics of the project are as follows: |
| 69 | + |
| 70 | +1. Goal: Create a universal multifaceted web framework in python |
| 71 | +2. Tasks: |
| 72 | ++ Find the good and bad sides of Flask, FastAPI |
| 73 | ++ Find the good and bad sides of Django |
| 74 | ++ Compare the capabilities of existing frameworks |
| 75 | ++ Selection of the best features |
| 76 | ++ Symbiosis of features into one whole |
| 77 | ++ Build project code according to SOLID and OOP principles, easily extensible, scalable and complementary. |
| 78 | ++ Make the code fast and productive, give freedom to the user and developer |
| 79 | +3. Problem: at the moment there are very few universal frameworks that allow you to create both a large monolithic application and a fast small service. |
| 80 | +4. Relevance: the web sphere is very popular at the moment, the ability to work with web frameworks, abstractions, and know the structure of sites will help everyone. |
| 81 | + |
| 82 | +--- |
| 83 | + |
| 84 | +[Contents](./index.md) |
0 commit comments