Bootstrapping web application - PHP, Ruby, Python, Node.js - php

Question

Assumption 1: When running PHP via apache or nginx, each incoming request results in the script bootstrapping all of its include files, so essentially there is no shared memory, and the "world is recreated" upon each request.
Assumption 2: Node.js applications are bootstrapped when the server is started. The "world is only created once".
Are Python and Ruby applications bootstrapped in a similar way as PHP or as Node.js?
If possible, would appreciate some guidance regarding terminology: is this basically a question of multi-threaded or concurrency support?

Answer 1

It depends totally on how the application is run.
Most web applications in Python are run as servers which receive requests, rather than being a 'dead' script that gets called on request. "The world is created before the request arrives".
Note I didn't say "only once", as you phrased it.
The reason I phrase it that way is that there are different ways of serving python web applications.
Most python (web) apps are 'WSGI' applications. WSGI is a specification which basically requires the application (or framework) to have a single entry-point function:
def app(environment, start_response):
where environment is all the stuff like the address being asked for, cookies, request type, query args, etc. start_response is a callback function, which the app function needs to call with the response HTTP code, and headers.
start_response('200 OK', [('Content-type', 'text/html')])
for example. Once the this has been called, either the function needs to return the body of the response to be sent back to the client, or else to yield it back as a generator (for super big files).
All of this is usually handled by a WSGI framework, which does all that transparently, and provides a easier to write interface for writing your application logic.
In PHP, all your routes & routing is normally handled by apache (or nginx/php-fpm) running individual script files. This, as you rightly suggest, requires re-creating the whole world each time. With WSGI, the world is already created, and WSGI simply calls the application function each time a new request comes in. Most python based web frameworks have some kind of router, either the flask style:
#app.route('/elephants')
def elephants_view():
return 'view the elephants!'
or Django style routing table:
urls = [
(r'^/kangaroos$', 'views.kangaroos'),
]
# in views.py:
def kangaroos():
return 'kangaroos, baby!'
or other ways. There are many different WSGI frameworks which all have their pros and cons. Some of the popular WSGI-based frameworks include Flask, Django, Falcon.
There are many different ways to serve WSGI applications. Flask & Django come with basic development servers, which are single-threaded, and great for development, but not suitable for production.
Since they're single-threaded, "the world is only created once". So global variables last between requests, etc.
There are many other WSGI servers, which can serve any of the frameworks on top of WSGI. Waitress is a great pure-python one. uWSGI is another production grade server, as is gUnicorn, and many others.
These servers do NOT guarantee that global state is shared between requests, and will 'create the world' an unspecified (configurable) number of times. Some of them use a fixed number of workers, which the main incoming reciever will pass out requests to, others may spin up new worker threads or processes as they are needed.
Flask, and most of the other Python WSGI frameworks do have the concepts of 'Application Globals' which is how you can store data which must last the whole server lifespan. These special values are shared between 'worlds'. (By using magic rings and pools in a forest).
(Side note: For fun, I started writing a WSGI server using the very cool gevent async library, which does work in the same kind of manner as Node.js in that it is only a single process, which does as much as possible asynchronously (although without Node.js callback style...) in a single thread. It's very short, just one file, so it's pretty easy to see how it all works.)
Ruby is pretty similar to Python in this way, except the protocol is called 'Rack', rather than WSGI, and common servers are 'Puma', 'Unicorn' and 'Rainbows!'. Common Ruby Rack-based frameworks are 'Ruby on Rails', 'Sinatra', and 'Merb'.
One advantage of this kind of model is that you can create 'middleware' which sits between the application responder, and the WSGI (or Rack) server, and "does stuff" to the request on the way (such as minifying javascript, caching, logging, authentication, etc).
Another good introduction to WSGI, and how it works is in 'Full stack Python'.
There are other ways of writing web servers than using WSGI (or Rack). For instance, the Tornado and Twisted frameworks in Python allow a totally different asynchronous style of (web) app to be written. They are also using 'the world is created before requests come in' style servers.