I created a RESTful application in Python. I'm now trying to know what kind of server I should use to deploy the application. Currently I'm looking at Gunicorn, which is a WSGI server. But I often hear about this popular web-server Apache as well.
So my questions are:
What is the difference between the WSGI and web-server?
If I don't need a public domain (i.e. my application only needs to
run within the private network), should I use WSGI or a web-server?
WSGI is the standard interface for running Python web server applications. Python frameworks already implement this standard so you don't need to worry about this. There is no point in using apache if your application is written in Python.
Related
I'm looking at the WSGI specification and I'm trying to figure out how servers like uWSGI fit into the picture. I understand the point of the WSGI spec is to separate web servers like nginx from web applications like something you'd write using Flask. What I don't understand is what uWSGI is for. Why can't nginx directly call my Flask application? Can't flask speak WSGI directly to it? Why does uWSGI need to get in between them?
There are two sides in the WSGI spec: the server and the web app. Which side is uWSGI on?
Okay, I think I get this now.
Why can't nginx directly call my Flask application?
Because nginx doesn't support the WSGI spec. Technically nginx could implement the WSGI spec if they wanted, they just haven't.
That being the case, we need a web server that does implement the spec, which is what the uWSGI server is for.
Note that uWSGI is a full fledged http server that can and does work well on its own. I've used it in this capacity several times and it works great. If you need super high throughput for static content, then you have the option of sticking nginx in front of your uWSGI server. When you do, they will communicate over a low level protocol known as uwsgi.
"What the what?! Another thing called uwsgi?!" you ask. Yeah, it's confusing. When you reference uWSGI you are talking about an http server. When you talk about uwsgi (all lowercase) you are talking about a binary protocol that the uWSGI server uses to talk to other servers like nginx. They picked a bad name on this one.
For anyone who is interested, I wrote a blog article about it with more specifics, a bit of history, and some examples.
NGINX in this case only works as a reverse proxy and render static files not the dynamic files, it receives the requests and proxies them to the application server, that would be UWSGI.
The UWSGI server is responsible for loading your Flask application using the WSGI interface. You can actually make UWSGI listen directly to requests from the internet and remove NGINX if you like, although it's mostly used behind a reverse proxy.
From the docs:
uWSGI supports several methods of integrating with web servers. It is also capable of serving HTTP requests by itself.
WSGI is just an interface specification, in simple terms, it tells you what methods should be implemented for passing requests and responses between the server and the application. When using frameworks such as Flask or Django, this is handled by the framework itself.
In other words, WSGI is basically a contract between python applications (Flask, Django, etc) and web servers (UWSGI, Gunicorn, etc). The benefit is that you can change web servers with little effort because you know they comply with the WSGI specification, which is actually one of the goals, as stated in PEP-333.
Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to name just a few 1. This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa.
A traditional web server does not understand or have any way to run Python applications. That's why WSGI server come in. On the other hand Nginx supports reverse proxy to handle requests and pass back responses for Python WSGI servers.
This link might help you: https://www.fullstackpython.com/wsgi-servers.html
There is an important aspect which we are missing . Flask and Django are web frameworks and we build web applications out of them . uWSGI or Gunicorn process the framework files . Consider it as a software application sitting in between the Django app and Nginx . uWSGI and Nginx communicate using WSGI but there is no communication interface between Django and uWSGI . Check out this video https://www.youtube.com/watch?v=WqrCnVAkLIo
In simple terms, just think of an analogy where you are running a CGI or PHP application with Nginx web server. You will use the respective handlers like php-fpm to run these files since the webserver, in its native form doesn't render these formats.
Why is it recommended to deploy a Flask app using Apache or Nginx? It has a server built in, can't it just be deployed by running python app.py and opening the correct ports in the firewall?
Werkzeug's WSGI server is not meant for use in production. It is provided as a convenience during development. It was not developed with security or performance in mind (by default it only handles one request at a time). Use a real WSGI application server such as uWSGI or Gunicorn for performance, and proxy it through a real web server such as Nginx for performance and security. Web servers are good at queueing requests/responses, can serve static and other content at the same time, and are designed to handle SSL. WSGI servers are good at coordinating multiple requests across an app efficiently. Werkzeug was designed as a WSGI library, not as a web server or WSGI server.
The docs tell you directly not to use the development server in production.
You can use the builtin server during development, but you should use a full deployment option for production applications. (Do not use the builtin development server in production.)
Additionally, web servers run as root (then drop privileges), so they can listen on the standard ports 80 and 443. You should never run an application as root, and so you would only be able to bind to ports above 1024, so users would have to know the port rather than just the domain.
I am new to Flask Web with Python. I developed a simple Flask with Pycharm. Now I want to deploy it on my college server. I remember when I develop php web app I used to copy it to www folder in var and run it from there.
Can someone explain me how do I deploy python web app in Linux production server.
First, you need to figure out what your server provides from its sysadmin. There are tens of ways to do this, and all of them have different answers.
Given that you have used php on the system before, I'll assume you are using Apache httpd.
First, you would need to have a wsgi provider installed (e.g. mod_wsgi) , and then wire your application into the wsgi provider.
See the mod_wsgi page and flask docs for more information on how to precisely do this.
https://code.google.com/p/modwsgi/
http://flask.pocoo.org/docs/0.10/deploying/
Another option is to have python bring its own webserver and optionally have a proxy redirect / load balance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am new to Python and i am not able to understand the server concepts in Python.
First of all what is WSGI and what are Wsgiref and Werkzeug and how are they different from CherryPy WSGI Server, Gunicorn, Tornado (HTTP Server via wsgi.WSGIContainer), Twisted Web, uWSGI, Waitress WSGI Server.
If i need to develop a web application from scratch, i mean starting from the beginning, where should i start, my company needs a custom framework and the application is based on critical performance overheads.
Please help and explain how they are different.
P.S I am not a beginner to programming.
WSGI is just a set a rules to help unify and standardize how Python applications communicate with web servers. It defines both how applications should send responses and how servers should communicate with applications and pass along the environment and other details about the request. Any application that needs to communicate with any web server implements WSGI, because its the de-facto standard and recommended method for Python. WSGI came about to unify the other implementations (CGI, mod_python, FastCGI).
wsgiref is a reference implementation of the WSGI interface. Its like a blueprint to help developers understand how to implement WSGI in their own applications.
The other things you mentioned are all different applications that implement the WSGI standard; with some exceptions:
Twisted is a library to create applications that can communicate over a network. Any kind of network, and any kind of applications. Its not limited to the web.
Tornado is similar to Twisted in that it is also a library for network communication; however it is designed for non blocking applications. Things that require a long open connection to the server (like say, an application that displays realtime feeds).
CherryPy is a very minimal Python framework for creating web applications. It implements WSGI.
Werkzeug is a library that implements WSGI. So if you are developing an application that needs to speak WSGI, you would import werkzeug because it provides all various parts of WSGI that you would need.
uWSGI is a project that allows easily hosting of multiple web applications. The fact that it as WSGI in the name is because WSGI was the first plugin that was released with the application. It is perhaps the odd duck in this list because it is not a development framework, but more of a way to manage multiple web applications.
Web servers that implement WSGI can talk to any application that also implements WSGI. modwsgi is a popular implementation of WSGI for webservers; it is available for both Apache and Nginx and for IIS there is the isapi wsgi module.
I was wondering what is the advantages of mod_wsgi. For most python web framework, I can launch (daemon) the application by python directly and serve it in a port. Then when shall I use mod_wsgi?
Since I answered your other question regarding Flask, I assume you are referring to using Flask's development server. The problem with that is it is single threaded.
Using mod_wsgi, you would be running behind apache, which will do process forking and allow for multiple simultaneous requests to be handled.
There are other options as well. Depending on your particular use case I would consider using eventlet's wsgi server.