# An introduction to technology stacks - 1 of 2
# 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
sometimes often regret my decision about switching languages.)
# The freedom to screw up
# Other stacks
# 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?
Another difference is that SPA frameworks like Vue and React decouple the frontend from the backend.
# Search engines
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...