# An introduction to technology stacks - 1 of 2

A pile of computer processing units

# Author: Brian King | Date: Monday 15th June 2020, 2 years ago.

Software engineers are constantly presented with new languages, new frameworks, and new libraries. Our magpie attraction to "new and shiny" trinkets is never satisfied. We actively trawl the Internet for the latest technical innovations and current programming trends. But we also have fun assembling the least amount of technology that achieves the most amount of work.

# My first stack

I have a soft spot for the LAMP stack (Linux, Apache, MySQL, PHP). I adopted it in the mid 2000's and stuck with it for ten years. Sadly, I never built anything substantial with those tools. Around the late 2000's I started using WordPress. Yes, I was pushing not-very-popular content out the door but I felt the WordPress CMS (content management system) was very restrictive. I was able to build a couple of personal plugins but the whole ecosystem felt oppressive. I was yearning to code without borders.

# Making the switch

2015 saw the release of PHP 7.x but, out of the corner of my eye, I also noticed the release of ES6 (later renamed ES2015, which stands for ECMAScript 2015). I had a choice: Stick with PHP and learn the differences between PHP 5.4 and PHP 7.x or switch to JavaScript and learn a whole new programming language? There was a single piece of technology that swayed my decision: Node. The idea of using a single programming language on the (client) frontend and the (server) backend seemed very attractive. So I made the jump to JavaScript. (I sometimes often regret my decision about switching languages.)

# The freedom to screw up

It has not been an easy five-year journey. From JavaScript to Node, from Angular to React, from Vue to Nuxt, it has been a constant learning experience with occasional bouts of code. It may sound like I'm complaining but I am an old man and it is my prerogative to rail against the world.

# Other stacks

We have the MEAN stack (MongoDB, Express, Angular, Node), the MERN stack (MongoDB, Express, React, Node), the MEVN stack (MongoDB, Express, Vue, Node), the JAMstack (JavaScript, APIs, Markup), and the full stack. Each element in a stack performs a specific task. Grouping these tasks together provides a programmer with a fully-rounded DX (developer experience). A technology stack provides a solo developer - like myself - a DX that covers the frontend, middleware, backend, and database (sometimes called a data store). I am fully immersed in a project when I get to 'touch' all the different aspects of an app. A happy coder is a productive coder. (Actually, a happy coder automates every manual task in range of his/her wi-fi signal.)

# Stack elements

A typical stack brings together a number of technologies. Each technology has a particular task. These tasks work collectively to provide a consolidated UX (user experience). For example, the MEAN stack consists of:

  • MongoDB, a database,
  • Express, a middleware server,
  • Angular, a frontend framework, and
  • Node, a backend server.

Let's have a look at how a frontend framework, a backend server, a middleware server, and a database work together in a classic, client-server model.

# Dynamic website built using a client-server model

When a client - the user's browser - visits a dynamic website, the backend server returns a UI (user interface) and interaction layer that is built with a template from the frontend framework. For instance, when the user clicks on a link where a record is needed from the database:

  • the backend server accepts the request from the client (browser),
  • the backend server sends a request for the record to the middleware server,
  • the middleware server accepts the request from the backend server,
  • the middleware server sends a request for the record to the database,
  • the database accepts the request from the middleware server,
  • the database runs a query to find the record,
  • when found, the query returns the record to the database,
  • the database responds to the middleware server by returning the record,
  • the middleware server accepts the response from the database,
  • the middleware server responds to the backend server by returning the record,
  • the backend server accepts the response from the middleware server,
  • the backend server builds the record into an HTML template designed by the frontend framework,
  • the backend server responds to the client by sending a freshly built HTML file,
  • the client (browser) accepts the response from the backend server, and
  • the client (browser) renders the HTML file and displays it to the user.

This example describes a typical request-response scenario that is used by the client-server model. But now we now have an alternative way of doing things.

# Dynamic website built with a single page app

There is absolutely nothing wrong with building dynamic websites using the client-server model. There's mostly nothing wrong with the client-server model. All right, you caught me listing some of the things that may be wrong with the client-server model:

  • The client-server model is slow compared to SPA's (single page apps).
  • The client-server model is expensive due to the number of services.
  • The client-server model is fragile due to the number of services.
  • The client-server model is complicated due to the number of services.
  • The client-server model is complicated due to the number of requests and responses.
  • The client-server model is difficult to scale.
  • The client-server model is expensive to scale.
  • The client-server model is time-consuming to maintain.
  • Adding new features to the app can bring down the whole site.
  • I just want to write code so why the hell am I nursing all these bloody servers?
  • Let's include load balancers because I'm not busy enough as it is!!
  • Oh, and client-server security is a damn nightmare!!!

But the client-server model is a well-understood way of building dynamic websites. I don't know any other way to build dynamic websites so I rip out my hair in silent rage. Then I blame Monty, the dog, for shedding everywhere. (Who scolds me in return: "This is grey hair. I'm not a grey dog! Snap out of it, dad!! You're spinning out of control!! Pull up!! Pull up!!")

So, what makes SPA's different to the client-server model?

A device - like a mobile phone, for instance - downloads an SPA from the backend server. The first-page load time may take awhile, but code-splitting helps to speed things up. Once the SPA is loaded, the JavaScript code within the SPA can request network resources that make up the different views of the SPA without needing the backend server or a middleware server. The JavaScript code can request, and receive, networked resources as long as the SPA is authorised to use the API (application programming interface) that accesses, and then returns, those resources.

Another difference is that SPA frameworks like Vue and React decouple the frontend from the backend.

# Search engines

Search engines don't like dynamic websites, regardless of how they're built (client-server model or SPA). A dynamic website is built with code - JavaScript, PHP, Python, etc. - but search engines are looking for meta tags that are typically found in the HEAD section of HTML (hypertext markup language) pages. When a search engine scans a dynamic page for meta tags, the site will build that page. By the time the page is built, however, the search engine has already decided the page doesn't exist and moves on. Dynamic pages load really fast for humans - usually within a second or two - but they don't build fast enough for a search engine.

Luckily for us, there is a clever solution: Static pages.

# The return of static pages

I remember hand-coding HTML pages with a simple text editor back in the 1990's. That was my first exposure to online publishing and static pages. I also added CGI scripts to my pages that counted the number of visitors I had (the only time the counter changed was when I visited the page to see if the counter had changed.) Then I moved on to other editors like Netscape Composer, Microsoft FrontPage, Macromedia Dreamweaver, Sublime Text, and VS Code. Now static pages are back, like an old friend. Or a recurring STD.

The idea is simple: Take all the content that makes up a dynamic SPA, render that content as HTML pages, and host those pages on a CDN (content delivery network). It turns out that static pages load even faster than an SPA can render. That's amazingly fast. Another advantage - which is also a disadvantage that I will cover in a moment - is a lack of server-side rendering. Remember, the content is rendered first, and then the CDN hosts the resulting HTML pages. Yet a third advantage is that, with a bit of tweaking to each view, relevant meta tags for each HTML page are now available to every search engine.

But every solution comes with it's own problems.

# The end of dynamic content?

The main problem with a CDN is the lack of server-side rendering support. How can we access the content in a database - like SPA's - while supplying meta tags for search engines - like static pages?

Stay tuned for the next article where I look into a proposed solution using actual technologies. Wheee, down the rabbit hole we go...