0

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?

  • There is no such things as a "complete stack". No website is going to use every possible technology. You are free to pick and choose which of these technologies you need and want. There are many sites that don't use many client side technologies, databases, server side languages, caching, extra storage, or load balancers. Really only required things are a web server and HTML. Everything else on your list is extra. Databases and server side languages are really common, but there are a lot of static websites out there that just don't use them. – Stephen Ostermiller Nov 9 '17 at 20:50
  • I don't think you would ever want to use both NodeJS and Ruby on Rails for the same project. They are server side frameworks in separate languages with separate web servers. Gluing them together would be a pain and would probably end up with lots of duplication of efforts, code, and servers. – Stephen Ostermiller Nov 9 '17 at 20:52
  • So just to clarify NodeJS is both a server side framework and a server (you can use both of these functionalities together or separately) vs Ruby on Rails is a server side framework that needs to be run on a server whether that be Apache, etc? All of these need to be run on a physical server which could be AWS or my own deployed hardware. I never meant this is everything that was ever needed or every website uses it all but more just a sketch of a possible stack for a full bodied web app. – Pearl Nov 9 '17 at 21:40
  • That seems to be the typical way to run NodeJs, but NodeJS could be run from Apache using MOD_CGI – Stephen Ostermiller Nov 9 '17 at 21:45
3

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.

  • 1
    Perl is definitely under appreciated as you mention in your bio. Also, I thought I was the only one who has used the term backing store here. I have not kept up with the new technologies since I am retired, but it certainly sounds like you have! Cheers!! – closetnoc Nov 10 '17 at 5:02
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.