Full Stack Basics for the Non-Developer, Part 3
Here's part #3 in the series explaining our "full stack" at a high level. If you missed part 1, or part 2 make sure to give those a read first. If you prefer, you can read the long-form post with all the content in one. Again, feel free to call me on any technicalities or suggest changes/additions in the comments!
9 - End User
Still with me? Great! Now that we've covered the basics of a developer writing and deploying code all the way to a production server, let's jump all the way to the bottom of the diagram and work our way back up from the end user to discover how they reach the website on the production server. This same process applies to how a user visits the staging server and development server (if publicly accessible) as well. The user is going to need a computer (their own "localhost"), but they don't need any particular software installed other than a web browser!
10 - Browser
Ah, the good old web browser. Luckily the days of Internet Explorer 6 are over and we've moved on to browsers that can handle the plethora of modern languages, frameworks, and applications that make up the many pieces and parts of a website. We generally favor Google Chrome. We're now on the (xx) client-side in the client-server model, or the frontend presentation layer portion of a website. Here's the part where you regularly remind website users (and yourself), "did you clear the cache?" when expected changes to a site aren't showing up. Caching layers appear all over in the web development stack, but your browser will make ample use of (xxi) browser caching in order to speed up your web browsing experience at the expense of potentially failing to deliver the newest content.
Let's talk some technologies and concepts when it comes to the client side:
- (q) HTML makes up the building blocks of every website. Note that many programmers will correct you if you call it a programming language, as it's actually a markup language. HTML is interpreted by the browser using the DOM convention for structure, resulting in the website you see in front of you! HTML can also be used to build entire static web pages without any dynamic code involved.
- (r) CSS comes in really handy at this point for your structured but unstyled website. CSS is a style sheet language that provides the look and formatting for HTML. CSS can be written in-line in an HTML document, but the modern standard is to have the HTML file reference the CSS file and keep all style information separate to make global style updates easier. We use SASS in addition to CSS to bring a bit more power to our frontend. SASS relies on similar principles to scripting languages to take SASS files and preprocess them into normal CSS much the same way preprocessed PHP code spits out HTML.
Note that the increasingly widespread acceptance of open source has allowed the frontend to become a much more viable and powerful playground for developers. Server-side backend languages are great for protecting proprietary code because the end user never has access to that code, but frontend languages are all sent to the browser for interpretation, so the source code is all accessible simply by nature of where it's processed.
So far we've covered how the production server and the browser both contribute to creating the websites you browse every day, but there's one big question remaining to be answered: how are your browser and the production server communicating? That brings us to...
11 - ISP/The Internet
Oh right, there's that handy thing called The Internets, the handy series of tubes that has given purpose to and led to the development and maturation of every other part of the stack. Underlying the Internet are a number of important concepts. First off, remember that the Internet is essentially a huge internconnected web of smaller networks and numerous devices within those networks. Between all parts of all networks, connections exist comprised of either physical cables or over-the-air wireless (radio) connections. ISPs, or Internet Service Providers manage access to the Internet for private households and mega-corporations alike. Here is where battle over net neutrality is occuring, and you can probably see why it's important to the Internet's future that ISPs treat all data coming and going on their networks equally. ISPs are poorly regulated, and my hope is that they eventually fall under the same status as a public utility like sewer/water or electicity.
But back to the tech. ISPs are facilitating huge numbers of outbound requests from (xvi) user agents (browsers being the most common user agent involved when it comes to websites) seeking a destination production server and whatever it is that server has to return. The web browser's URL address holds the key to what it is being sought out and where:
- The (xvii) HTTP/HTTPS protocols specify the type of request being sent to the intended server, where Apache will interpret the request and provide the proper response.
- The hostname (the server's name, essentially) is made up of both the www and the domain name. Hostnames actually represent an (xviii) IP address and are intended as a human-readable alternative to typing in strings of numbers to reach target hosts. The www subdomain (or any other of subdomains that can be created) allows the host server to identify if a specific server or resource on a server is being requested. For instance, www exists as a hostname for metaltoad.com, but dgsdaghrwehr.metaltoad.com does not.
- The domain name consists of a top-level domain (.com in this case) and the unique name (metaltoad) that we registered for use as our human-readable represenation of our production server's IP address.
- The directory portion of the URL tells the server where within the overall server directory the requested file lives. The initial / indicates the server's root directory, so in this case the URL is requesting a file within the "files" directory, which lives within the "default" directory, which lives within the "sites" directory in the root directory. Confused? Directories are synonymous with the folders you're likely very used to using in your operating system's GUI file system browser. So just think folders inside folders.
- The file name is pretty straightforward. In this case, the requested file is a .jpg image. You'll see many URLs without a filename, and in these cases, there are rewrite rules within Apache that take a URL and determine which file to serve.
All of this relies on the overarching (xix) Domain Name System (DNS) comprised physically of a distributed network of domain name servers which handle translation of domain names and IP addresses. DNS specifies authoratative name servers for each domain name, and those name servers handle a zone file for each individual domain name. Within the zone file, a variety of DNS record types can exist. The two most pertinent for website purposes are A records (specifies the IP address for a hostname) and CNAME records (creates aliases from one name to another). Using our site's example, www.metaltoad.com has the following records in its zone file:
Metaltoad.com has an A record that specifies the host/server with an IP address of 22.214.171.124. There's also a CNAME that exists that ensures website visitors arrive at our website whether they attempt to visit http://www.metaltoad.com or the shorter http://metaltoad.com.
Note that ISPs also tend to employ some caching, and domain name servers assign individual DNS records a TTL (time to live) which (if you forget to lower the value prior to making record changes) results in the classic case of:
Developer: "We've deployed the site to production and pointed your domain name at the server. Congrats on your live site!"
Client: "But I pulled up the URL address and I don't see it yet."
Developer: "Oh right, well give it 24 hours for the site to propagate across the Internet."
That's a Wrap (For Now)
What started out as one blog post morphed into a series (as they tend to do) with a lot of information to absorb. If you picked up the overaching picture of how all these pieces and parts tie together, great. If you're still confused or have areas you'd like clarified or further described, let me know. I'm happy to make updates, so please leave a comment!
- Full Stack Python is a slightly more technical and much more in-depth look at the full stack with a specific emphasis on Python.
- The Google is a wonderful place where any sort of answer can be had as long as you know the question to ask.
- Stack Overflow is a big repository of development questions and answers. It's a lot of by-dev, for-dev reading, but armed with the Google you should be able to work your way through any sort of techincal topic to your heart's content!
- Atlassian's Git tutorial provides useful basics on Git and version control
- Github for Beginners provides some useful basics on Github and basic commands.
- MIT IT has a useful resource for learning more about the domain name system.
- DNSimple also has useful articles on DNS and record types.