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!

full stack part 3

View/download a full-size version here to follow along.

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.
  • (s) Javascript is our other go-to frontend language, bringing dynamic code to the frontend. Why have the server do all the work when your own computer+browser is plenty capable? One of the biggest breakthroughs Javascript has allowed is the ability to alter the contents of a website once it has completed initial loading from the server with asynchronous communication (AJAX). This allows for features you see in modern websites like "load more", form submission, search result autocomplete, and other tasks that might otherwise require a page reload and new information preprocessed on the server.

The HTML/CSS/Javascript cobination is a powerful one, but like much of programming, frameworks can speed up development significantly. I've used the term (xxii) "framework" (or the related "library" with the primary distinction being that frameworks are installed and run on your servers, while libraries are often hosted externally for a website to reference)  a few times already, so I should clarify what that's all about. Really all we're talking about is a bundle of code that has been abstracted to a general set of beneficial features for reuse and/or modification. We use quite a few frameworks and libraries in development. Drupal itself, while considered a CMS, is sometimes referred to as a content management framework due to the level of abstraction and multitude of potential use options it provides. jQuery is by far the web's most popular Javascript library, allowing for better separation of Javascript from HTML and better cross-browser compatibility out of the box. There are two key frontend frameworks that we make heavy use of at present:

  • (t) Foundation is a HTML/CSS/Javascript framework that is hugely beneficial when developing responsive websites. Given the request from just about every client project to build responsively, Foundation is useful in getting some out-of-the-box responsive benefits even before starting custom responsive work.
  • (u) AngularJS is a Google-developed Javascript MVW (as opposed to MVC) application framework that can relieve the backend of a large amount of templating work. We're doing more and more prototyping work in Angular, and an increasingly common scenario is using "headless" Drupal, or using Drupal as a framework for content management, and using Drupal's API to handle all templating and front-end development in Angular.

As mentioned above, unlike backend languages such as PHP (which takes client requests for dynamic content and interprets them into HTML on the server before being served to the client), frontend languages are delivered as written to the browser, and then any frontend scripts are run in the browser. The easiest way to visualize this is to pull up a web page's source code. You see client-side code (HTML, with links to CSS and Javascript files and libraries) but no backend languages, as those files have already run on the server and spit out their resulting code:

source code

Further, when you pull up Chrome's Developer Tools or a similar browser inspector (the best thing ever to happen to frontend development) and take a look at the files loaded by the browser, you can see HTML, CSS, and Javascript files, but no sign of any backend code:

network files

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:

URL address broken down

  • 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:

Metal Toad DNS

Metaltoad.com has an A record that specifies the host/server with an IP address of 54.186.179.92. 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."
Client: "Bummer."

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!

Additional Resources:

  • 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.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?