putting what we learned into context – wsgi and web frameworks a290/a590, fall 2014 10/16/2014

13
Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

Upload: camilla-gaines

Post on 29-Dec-2015

217 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

Putting What We Learned Into Context – WSGI and Web Frameworks

A290/A590, Fall 201410/16/2014

Page 2: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

Announcement

• You can take until Saturday @ noon for Lab 7

Page 3: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI Limitations

• CGI the way it was originally designed is not practical for large applications– Remember: Every time a request for a CGI script is

received, the web server will spawn a separate process (the Python interpreter) to execute the script.

– This is very inefficient and doesn't scale to large numbers of requests

Page 4: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI

• Despite this limitation, the model introduced by CGI is still followed in large scale web applications

Core Python Application Programming, Chun, 2012

Page 5: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI Alternatives

• Integrating the execution of script with the web server1. The server provides an API.2. A module implementing the API is written for a given

language.3. The module is loaded onto the server by the system

administrator/web developer.4. The script developer makes sure their code is written

in a way that respects the module's conventions.• Example: mod_python for Apache.

Page 6: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI Alternatives

• Server integration – some caveats– the module needs to be thread safe– a buggy module can interfere with the

performance of the server– to develop a module you usually have to code in

the language the web server was written in (C for Apache)

– the module has to keep up with changes to the language and the server API (happens rarely)

Page 7: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI Alternatives

• Running a CGI "server" outside of the web server– a single dedicated process responsible for

managing requests for CGI scripts– Example: FastCGI– Independent of the web server

Page 8: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

CGI Alternatives

• Drawbacks to CGI servers as external processes1. It has to provide support for the web server you

want to run it with2. It has to provide support for your language

• Both methods can be problematic for web framework which need to run on a wide variety of server configurations

Page 9: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

WSGI

• WSGI = Web Server Gateway Interface– an interface between the web server and the web

application– very general interface

• a WSGI application is a function that takes two parameters: a dictionary of environmental variables and a function to initialize the HTTP response

def simple_wsgi_app(environ, start_response):status = '200 OK'headers = [('Content-type', 'text/plain')]start_response(status, headers)return ['Hello world!']

Page 10: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

WSGI

• A WSGI server is also necessary– can be implemented as a stand-alone server– or it can be a third-party server module, e.g.

Apache's mod_wsgi• Advantages– web apps need to implement a single, very general

and very simple interface– web apps are independent of server– a WSGI server doesn't do a lot, hence it is easy to

implement

Page 11: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

WSGI

• Conclusion– WSGI is a higher level abstraction than the server

integration or stand-alone CGI server methods for executing CGI applications efficiently

– it separates the application from having to worry about server-level details

– is widely used in industry– a lot like the stand-alone approach, but more

general (WSGI defines an interface, it is not an application)

Page 12: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

Web Frameworks

• A web framework is a software framework that helps you with many low-level details inherent in web programming, such as:– reading and writing cookies– user authentication– session management– database access through ORM (object-relational mapping)– separation between appearance, business logic and data model

with MVC• That is, a lot of the tasks you implemented in the class

– in fact you may have the start of your own framework in your solution to the last lab

Page 13: Putting What We Learned Into Context – WSGI and Web Frameworks A290/A590, Fall 2014 10/16/2014

Future Reading

• Django - Popular Python web framework• Tutorial