the-rise-and-fall-of-the-full-stack-developer

https://techcrunch.com/2014/11/08/the-rise-and-fall-of-the-full-stack-developer/
I’d wager that there are zero individuals with advanced-level knowledge in each of these areas that would be capable of single-handedly delivering this next generation kind of application. Just keeping up with the advancements and new programming interfaces in each category is almost a full-time job.

We are in the midst of a rapid shift to more complicated technologies that, as in days gone by, require experts at each tier. Developing excellent iOS and Android applications requires experts in those platforms that understand the intricacies. Operationally, tending to new object databases such as MongoDB requires constant attention and tweaking. Running an application on cloud services such as Amazon requires knowing the ins-and-outs of its various services and expertise on how to failover across regions. Even the venerable web front-end has evolved into CSS4, JSON and JavaScript MVC frameworks, such as Angular.js and Backbone.js.

In this brave new world, it is critical to have at least one person with at least a functional understanding of each of the composite parts who is also capable of connecting various tiers and working with each expert so that a feature can actually be delivered. In a way, these tier-connecting, bridge-building software architects — who are likely experts in only one or a couple of tiers — are less full stack developer and much more full stack integrator.

Rest in peace, full stack developers. Welcome, full stack integrators, in addition to engineers with deep technical skills in particular areas. It’s a fascinating world of software out there and we need you more than ever.

Web Application Big Picture

Web server and application server and WSGI middleware

Python web frameworks had been a problem for new Python users because the choice of web framework would limit the choice of usable web servers, and vice versa.[3] Python applications were often designed for only one of CGI, FastCGI, mod_python or some other custom API of a specific web server.
WSGI[2] was created as a low-level interface between web servers and web applications or frameworks to promote common ground for portable web application development.

The WSGI has two sides: the "server" or "gateway" side (often a web server like Apache or Nginx), and the "application" or "framework" side (the python script itself). To process a WSGI request, the server side executes the application and provides environment information and a callback function to the application side. The application processes the request, and returns the response to the server side using the callback function it was provided.
Between the server and the application, there may be a WSGI middleware, which implements both sides of the API. The server receives a request from a client and forwards it to the middleware. After processing, it sends a request to the application. The application's response is forwarded by the middleware to the server and ultimately to the client. There may be multiple middlewares forming a stack of WSGI-compliant applications.
A "middleware" component can perform such functions as:
Routing a request to different application objects based on the target URL, after changing the environment variables accordingly.
Allowing multiple applications or frameworks to run side-by-side in the same process
Load balancing and remote processing, by forwarding requests and responses over a network
Performing content post-processing, such as applying XSLT stylesheets

https://www.fullstackpython.com/wsgi-servers.html
WSGI is by design a simple standard interface for running Python code. As a web developer you won't need to know much more than

what WSGI stands for (Web Server Gateway Inteface)
that a WSGI container is a separate running process that runs on a different port than your web server
your web server is configured to pass requests to the WSGI container which runs your web application, then pass the response (in the form of HTML) back to the requester

If you're using a standard web framework such as Django, Flask, or Bottle, or almost any other current Python framework, you don't need to worry about how frameworks implement the application side of the WSGI standard. Likewise, if you're using a standard WSGI container such as Green Unicorn, uWSGI, mod_wsgi, or gevent, you can get them running without worrying about how they implement the WSGI standard.

My understanding:

web server
- Apache
- Ngnix
WSGI server (middlewear)
https://www.digitalocean.com/community/tutorials/a-comparison-of-web-servers-for-python-based-web-applications
- Tornado
- Green unicorn
Application server (python app)
- various python framework
  - Flask
  - Django
Client
- Javascript and its framework (jQuery and AngularJS, React, etc)
Network
Build scalable app
- Router
- Load balancer
- Cache
- Proxy
- DNS
- AWS services and concepts
API
- Swagger
- RAML
Database
- a lot data engineering knowledge
- data processing and mining ... etc