Understanding of complete stack

Question

I am just starting out on the web and trying to understand a complete web stack, where the different pieces of it live and how they interact. I know there are infinite opinions but want to make sure my general understanding of the stack is correct.

My current understanding:

Client-side - Usually a combination of CSS, HTML, and JS. JS can be used in a framework like Angular, Vue, Backbone or React. These send a request to a web server.

Web-Server - This handles request from client computers. Popular web servers include Apache and Nginx. A web server can be run either locally (for testing), on a physical server or on the cloud (ex AWS EC2). These web-servers are configured using a server side language

Server-side Language - These are used to create the logic of the website. We program the web-server using a variety of languages (with popular frameworks in parenthesis): Ruby (Ruby on rails), Python (django, flask, pylons) and PHP (Laravel). Whenever these need to fetch data, they connect to a Database.

Database - A place to store a sites data. These can either be run on another local server running MySql and Postgresql or through the cloud like DynamoDB or MongoDB. Sometimes these databases can be too slow so we use another caching DB

Caching DB - A web application needs a caching system to reduce the load on the DB and to handle large amounts of traffic. We run another server, either on our servers or through the cloud like Amazon ElastiCache for Redis or self managed Redis on EC2. Sometimes we need to store large files.

Storage - When we need to store large files, instead of key-value pairs like in DB, we need a data store. This is good for photos and videos for example. We can either do this through a separate server or through the cloud (ex. S3)

NodeJS - After reading this post NodeJS can replace 2 pieces of this. It both serves as a server (replacing apache, nginx) and a backend language (replacing php, python, ruby on rails). Some people still use an apache server in front of the node server to reduce risk but this is becoming less and less necessary because NodeJS server is now pretty robust.

Extras - We can put Elastic Node balancers in front of our web server if we have more than 1 and want to help balance the request. CDN are a set of proxy servers geographically separated that cache some of the content. This reduces the load on our main server while giving higher performance.

So to summarize: client -> server (programmed by a backend language) -> A variety of different DBs, main (ex MySql), Cached (Redis) and Storage (S3).

What is wrong with my understanding of the stack? Also, reading this post, it sounds like Ruby on Rails is a web-server, just like apache, which seems to contradict my thoughts above. What am I missing here around server-side languages and web servers?

Answer 1

What you are missing is that the components of the stack are somewhat abstract concepts, so the delineations are not necessarily clean, on the server side.

Web servers typically sit in front of server-side language environments, sometimes they talk on sockets or pipes, or sometimes the language interpreter runs inside the web server's process space, and sometimes frameworks encapsulate both the web server and the language and in many such cases the web server is actually written in the same language as the application itself, and sometimes a web server is used in front of such frameworks in spite of the the fact that it isn't technically needed. A web server may, for example, be more efficient at serving up static files from disk than a framework is, because the framework is optimized based on a different objective than raw bytes of disk to wire throughput.

Sometimes there's HAProxy in front of multiple web servers and/or frameworks, routing requests to the application component that serves it. Sometimes "large file" storage is in an external service like S3, but this is logically "behind" the load balancing proxy or web server, so that all request pass through the web server... but sometimes it isn't, since S3, Google Cloud Storage, and other such "storage" services also have -- wait for it -- built-in web servers.

For that matter, the database could even have a built-in web server and programming language, for serving up APIs that are heavy on data but lighter on business logic.

The database may have a built in cache that can service queries faster than if handled by the normal processing path. The framework may have capabilities that assist with caching or cache integration.

There could also be an on-site HTTP cache (e.g. Varnish) in front of the web server or between the web server and the server-side language environment or framework.

The stack could also be divided externally at a load balancer or inside a CDN so that certain path patterns are served by one part of the stack, others by another, with minimal or no interaction among them.

And one component you didn't mention is the session store, which is typically some kind of database, but not usually the same database as the rest of the data, since it may need to be accessed with each page load and is responsible for traffic that differs in nature from the rest of the database traffic. It may have its own separate cache. It may have a backing store on disk, but since sessions are more ephemeral, it might not, or it might not have strong consistency guarantees, as these might not be as critical.

You have the right general idea. The issue is that the boundaries around server side components can be fuzzy.

Answer 2

The most common division is between the front end (the stuff that the site visitor interacts with) and the back end (all of the pieces required to assemble and deliver the actual pages). Front end developers tend to be familiar with some combination of HTML, CSS, and JavaScript. Back end developers will likely know something about systems administration (how to get/keep things running, monitor site performance, diagnose problems) and coding (maybe they will set up a content management system, simply set up a "static site," or use some combination of small programs known as microservices ... or some other method that accomplishes the same functionality).

The same person isn't necessarily conversant with all of the technologies, and in fact, some parts of the system can be hosted, letting the site owner focus on content rather than on the design (the "front end") or underlying technology/ies (back end).

The relevant "stack" then depends on what meets your needs.

You'll often see the term "stack" used to refer to some specific technologies often used together. I first heard the term a decade or two ago to refer to LAMP: Linux OS, Apache webserver, MySQL database, and either Perl, PHP, or Python scripting languages. It describes a small universe and a commitment to open source tools, and leaves a lot to the individual to assemble. It =is= true that if you have those things, you =can= build a website, but you may want more....

A more recent stack might be "MEAN" which stands for MongoDB (a new type of database, 'NoSQL'), Express (an application framework), and Angular.js and Node.js (Javascript frameworks).

What you'll notice is that "stack" really means, "a bunch of related technologies that work well together," but doesn't usually mean, "everything you need to do X". So, focus on what you are trying to do, and let the stacks crumble (or not) as helps you move forward.