
## How does Javascript code execute?
In brief, Javascript is a single-threaded language, meaning it must complete execution of it’s active snippet of code prior to moving on to the next snippet of code.  If that is the case, how is it possible that Javascript is able to delay execution of a snippet until a certain amount of time has passed (using the setTimeout function for example)?

The answer lies in Javascripts intimate connection with the Web API.

Stepping back a bit, what does it mean when we say Javascript is single threaded?  In computer science terms, a thread is the smallest sequence of programmed instructions which can be managed by a scheduler.  In layman’s terms a thread is a task which is given to the scheduler to execute.

Javascript, being single-threaded, means that it will execute tasks (in this instance, snippets of code) in the order the code is provided, reading through line by line until all code has been executed.  If you’re familiar with the concept of a call stack, you can think of every javascript file as a unit on that call stack to be executed.

So what happens when you include a setTimeout function within that executable code?  The answer lies in the intimate relationship between Javascript’s event queue, event loop, and the Browser API.

## Call Stack, Callback Queue, and Event Loop
### A Restaurant Analogy
I’m big into analogies, and this is one of the cleaner ones I can make.  Imagine Javascript is a restaurant with a kitchen, a waiter, and an individual named Frank  eating a large quantity of pancakes.

Each pancake represents a code snippet to execute.
The stack of pancakes delivered on each plate represents the Call Stack.
Frank represents the Javascript Engine executing the code snippets
The kitchen represents the Browser API (sometimes called the Web API)
The waiter communicates with the kitchen and Frank, representing the handoff of Browser API requests and the delivery of “cooked” pancakes, or new code to be executed.

In this world, Frank is particular in how he eats and carries four key traits in his eating habits.
He only eats pancakes
He will eat as many pancakes as he is served
Everytime he finds a blueberry pancake, he sends it back to the kitchen to have the blueberries removed
He will only eat one pancake at a time, pulling it off the top of the stack of pancakes, placing it on a separate dish, and eating it to completion.

Frank shows up to the restaurant and immediately begins consuming pancakes.  On his plate he has three pancakes, he carefully takes the first one off the stack, transfers it to a new plate, finds that it is a plain pancake and consumes it.  Once he finishes eating that pancake, he removes the second pancake, transfers it to a new plate, and finds that it is a blueberry pancake.  Frank is distraught, he calls over the waiter and says, “I get migraines when I eat blueberry pancakes, can you please have them remove the blue berries.”  The waiter dutifully takes the blueberry pancake back to the kitchen and says, “I promise we’ll make this into a plain pancake for you.”

Frank, an ever hungry man, goes to the stack of pancakes on his plate and finds the third and final pancake sitting there drenched in syrup.  He takes the pancake, puts it on a new plate, finds that it is a plain pancake, and consumes it.

He then looks at his plate, and finds no pancakes there.  He then asks the waiter, “was the kitchen able to fix that pancake?  Is there more for me to eat?”

The waiter rushes back to the kitchen and returns carrying a new plate of pancakes for Frank, “The kitchen apologizes for the blueberry mistake, here’s a stack of pancakes on the house.”

Frank looks at the stack, and begins his consumption ritual.  Pulling the top pancake off, checking to see if it has blueberries, eating it if it does not, and returning it to the kitchen if it does.


### Translating the Analogy
This rough analogy explains the general flow of execution and communication between the Javascript engine and the Browser API.  Javascript will execute all code snippets in the order they are received.  In this instance, Frank see’s the blueberry pancake and sends it back, but he continues eating the existing pancakes on his plate.  The Javascript engine performs the exact same process; whenever Javascript recognizes a function which should be executed in by the Browser API (like setTimeout) it will ‘hand off that snippet of code’ to the Browser API and will continue executing the code still on it’s plate (in the call stack).

If it runs out of code to execute in the call stack, Javascript will check the event queue for new code blocks to execute (just as Frank checked with the waiter to see if the pancakes were ready).  In the case of setTimeout, if the time has elapsed on the setTimeout function, the code within that setTimeout will be added to the Event Queue ready to be executed (or the waiter will come back with a plate of pancakes for Frank to eat).  Javascript will then add that code to the call stack and will begin executing it in order.

In this analogy, Frank’s constant communication with the waiter, and the waiter sprinting back and forth from Frank to the kitchen to satiate Frank’s insatiable hunger represents the overall event loop executing at all moments within Javascript.

### Putting it into Practice
When I was doing a bit of research how to teach this concept, I stumbled on the following tool which neatly illustrates this concept.

[Executable Example](http://latentflip.com/loupe/?code=CgoKdmFyIHJlc3VsdCA9IDA7Cgpmb3IoaT0wOyBpPDM7IGkrKykgewogICAgc2V0VGltZW91dCgKICAgICAgICBmdW5jdGlvbigpeyAKICAgICAgICAgICAgcmVzdWx0ICs9IGk7IAogICAgICAgICAgICBjb25zb2xlLmxvZygiVmFyaWFibGUgJ2knIGluc2lkZSBTZXRUaW1lb3V0OiAiLCBpKQogICAgICAgICAgICBjb25zb2xlLmxvZygiVmFyaWFibGUgJ3Jlc3VsdCcgaW4gc2V0VGltZW91dDogIiwgcmVzdWx0KTsKICAgICAgICB9LCAzMDAwKTsKfQoKY29uc29sZS5sb2coIlZhcmlhYmxlICdpJyBvdXRzaWRlIFNldFRpbWVvdXQ6ICIsIGkpCmNvbnNvbGUubG9nKCJWYXJpYWJsZSAncmVzdWx0JyBvdXRzaWRlIG9mIFNldFRpbWVvdXQ6ICIsIHJlc3VsdCk7!!!PGJ1dHRvbj5DbGljayBtZSE8L2J1dHRvbj4%3D
)

If you open up the console in the Chrome Dev Tools, you'll see the order the console.logs are executed.




Analogy: The Javascript engine as understood from a server and consumer of pancakes. A beginners primer on asynchronous behavior wihthin Javascript

Aysnchronous Pancake Delivery in Javascript

### The Analogy
When I think of rendering a webpage I liken it to creating a piece of art.  By happenstance, many of the metrics used to analyze the optimization of various websites happen to fit in nicely with this analogy.  Metrics like, First Paint, First Contentful Paint, First Meaningful Paint - all of those are measuring in various ways the speed at which your site and content load onto the page.

In this analogy, we have two key components: the server, the client, and the DOM.  In this analogy, the DOM represents the canvas of paint, the client represents the painter, and the server represents the commission request for painting.


### Server Side Rendering (SSR)
When the internet was first getting started, just about everything was rendered on the server side.  For the most part, this was done because of limitations around computer speed.  In these early days of computing, shipping large quantities of information over the web was highly taxing; communication, browsers, everything at that time (as you would expect) was significantly less sophisticated and slower than it is today.

In line with the analogy, all paintings requested from the server were prints and occasionally they were paint by numbers.  The server could adjust the painting, but for the most part the painting was already created in templates which are immediately shipped and sent out to the canvas of the DOM for the browser to render.

Some languages, like Pearl and PHP, would create templating libraries where you would inject variables into HTML templates.  The template would then render the final HTML with the variables you are using.

There are two key problem with this:
You have to wait for the server to render the page (fill in those variables)
The greater the burden on the server means you will have a greater challenge to scale and have information update dynamically.

### Client Side Rendering (CSR)
As computers and browsers became faster and more adaptable, there was a shift towards client side rendering.  Frameworks like React and Angular capitalize on this pretty heavily.

In client side rendering, the burden of dynamic rendering can happen on the front end.  Rather than creating a template which the server renders, you make API calls to the backend server which collects specific data and renders them inside your components (I like to think of components as the much more able and modular siblings of those old PHP templates).

This significantly improved the responsiveness of websites, enhancing the overall user experience as they navigate through organisms of modularized components.

In line with the analogy, commission requests were sent to the server and the server responded with a set of instructions (written in Javascript) for the painter to paint upon the DOM.  The painter then executes all of the instructions and dynamically paints the DOM with all of the components necessary to fully construct your website.

The downside to this is on the search engine side.  Search engines will look at your HTML file and derive the content of your side from that html - with client side rendering, you often will have an HTML file with only one div in in - entrusting the browser to dynamically inject the content off of that single div.  Search engines have been improving on this front - which we will discuss in another article.



### The Value of Next.JS
Next.js is an isomorphic combination of each of these rendering methods.  Next will enable engineers to partition out their sites so they can have all three rendering methods.  This allows engineers to optimize their websites for speed, responsiveness, and search engine querying without a tremendous deal of effort.

Using Next, an engineer can render static components which are optimal for search engine optimization, parts which are dynamic are server side rendered, and that everything else on the page is client side rendered.  Capturing the key value adds of each rendering method, while minimizing their potential downsides.

In this instance, we have a nice hybridized workflow between the commission requests, the painter, and the canvas.  Those aspects of the canvas which require quick viewing and which need to be read by machines (like search engines) will be sent directly from the server.  Meanwhile, those aspects of the canvas which are a bit more dynamic will be painted on the fly by the Javascript code executing.


Analogy:  Painting and its relation to  various server side and client side rendering advantages

Paint by Render

## Overview
When thinking about system design and requests being submit and received by your server, I like to draw a parallel with car manufacturing.  I’ve heard analogies using a restaurant with various lines chefs used nicely, but I’ll save that analogy for discussion on the value of microservices within backend design.

## Background
A bit of background is required for those not familiar with Computer Science in how data is transferred between systems before I can fully dive into this analogy. In engineering, we use the term “traffic” or more formally, “Network Traffic”.  Again, I find myself in a situation where the analytics used to describe the efficacy of your network tie in nicely with the analogy I’ve chosen.  Network traffic represents the amount of data moving across a computer network at any given time.  What does that mean?

Anytime you go to a website, data is being transferred between a sending device and a receiving device.  In most cases, the sending device will be the server serving up the resources to power the site and the receiving device will be the browser which is assembling and executing the data from that server.  There are other steps including communication with a Domain Name System (DNS) a Content Delivery Network (CDN) and a handful of other things which enable and speed up the efficiency of receiving the data, but for the purposes of this article, we are focusing on the communication between the server and the browser.

### Now, how exactly is that data transferred?
It’s reasonable to assume that all data in a single burst.  The browser says, “Hey, I need an HTML file to paint on this DOM” and the Server says, “Here’s your HTML file.”  For small data items, this is indeed how it works.  But what happens when you have a larger sum of data to transmit?

It’s much more efficient and robust to break up large data transactions into smaller packets and submit each of those smaller packets across the internet.  Why?  Because what if the receiver is not ready to receive the information - what if there is an error and communication somehow stalls or is broken during receipt?

Breaking this data into smaller packets enables a recipient to acknowledge they are receiving data, and gives the recipient a clue on how many data packets they are going to receive.  They can then let the sender know when a packages was successfully received, and (more importantly) can let the sender know when an error occurred and a package needs to be resent.

The requester can then combine each received package into the larger data file as each successful package is received.

## The Analogy
With that background, let’s think of each of these packages as cars which the server builds and then sends out along on a single lane road.  Between the browser and the server, that’s largely exactly what is occurring.  The browser will request packages that it needs, and the server will compose those packages to be sent along the treacherous road that is an HTTP request.

If we imagine a single user on a website requesting that information from the server, the process is simple - but what if we imagine a million users all hitting the same site at the same time?  That’s a lot of cars, a lot of packages, which the server has to build and send out to a lot of different browsers all at once.  So, how does the server handle that?

## Scaling
There are two options to discuss.  First, you can make a bigger car factory.  If pay to decrease the time that it takes to build those cars by building a super car manufacturing facility, you can quickly process requests and get those cars (or packages) out to every browser that is requesting them.  Second, you can duplicate your existing car manufacturing facility and distribute the load of creating those cars across each facility.

These two options are called Vertical and Horizontal scaling methods respectively.  With vertical scaling you pay to have a computer with greater processing speeds - something that can really quickly turn out those packages and send them along the road of the internet.  With horizontal scaling, you duplicate your existing manufacturing facility a hundred times over (something which is significantly cheaper to do when discussing software rather than actual manufacturing facilities) and you distribute the load of creating those packages across many different computers with smaller computing power.

With tools like Docker and the advent of virtual machines (think of each machine as its own manufacturing facility) the ability to duplicate existing environments and horizontally scale is often a cheap and reliable solution to scale lots of network traffic all at once.  But what do those data highways look like?

### Intro to System Design with Horizontal Scaling
Moving away from the single lane road of an HTTP request, and diving deeper into the package construction when horizontally scaling - let’s imagine that a Server is a massive city with thousands of requests being made for new cars every millisecond, and thousands of new cars being made every moment.

What’s the first thing you anticipate you might need is… directions to each of the manufacturing plants.  A hundred requests for cars come in at roughly the same time - you have 50 manufacturing plants ready to make the cars and send deliver them - step one.  How do you ensure you use all of your manufacturing plants efficiently?

### Load Balancing
You don’t want to send all of these requests to the same manufacturing facility, as it can’t create two cars at once and it will have to add new requests to the queue.  The answer lies in the term “Load Balancing”.  A load balancer’s key goal is to receive all of these requests for data and redirect the request to a virtual computer which is currently not making a data package.

Popular load balancers like Nginx, Azure Load Balancer, and AWS Load Balancing and each of those can distribute the load to a manufactucturing facility that is not currently in service.

Now we’ve solved the problem of getting requests to the right manufacturing facility - but we have a new problem.  Right now (and I haven’t mentioned this) every car manufacturing facility needs to request the blueprint from the Auto Designer on how to make the car every single time a request is made.

As you can image that might create a potential bottleneck on the Automobile Designer or (in this analogy) the database.  So how can we circumvent the need to request the blueprint every single time?

What if we stored the blueprint at the manufacturer?  If we had a blueprint of the most commonly selected cars, we could limit the number of calls heading out to our Automobile Designer and we could limit the impact of that bottleneck.

### Caching
The general concept of storing commonly requested data in a layer away from the database is called caching your data.  Caching occurs to optimize fetches across the entirely of the web, whether that is in commonly requested IP addresses, images when you visit the same website multiple times, or (in this case) commonly requested data items feeding back to a browser.

There’s a limit (or there should be) to the number of blueprints you want to store in a cache.  I say there should be, because maintaining full duplications of the database would be highly resource intensive and there is a tradeoff between the number of blueprints stored and the efficiency gains of a cache.

So, how do we decide what to and what not to include in a cache?
If you again take the scenario where you have 100 blueprints for different cars (or data packages), your goal is to find the data that will reduce the requests on your Auto Designer database the most.

One manner of doing this is to store the data that was requested soonest. Say you have a cache with the ability to only store three blueprints and requests come in, in the following order.

Camry
F-150
Camry
Model S
Model S
F-150
Camry
SmartCar

Visually, you can tell storing in a cache the data for a Camry and an F-150 would reduce the blueprint requests to the Designer fairly substantially.   If you requested the data that was last fetched, the blueprints stored in your cache would be:
SmartCar
Camry
F-150

There is a greater likelihood that the cars most commonly requested will ensure their presence in your cache, because… they are most commonly requested.

But, what is that SmartCar doing in there?  Is it doing any good?
The short answer is, it might be.  In situations where you have more varietal fetching and where you aren’t able to always predict the most common fetches, doing a time based caching store will capture those trends.

The perfect example of this might be someone searching umbrellas on a rainy day.  Searches for umbrellas go up as people realize they need an umbrella.  While it may not be the most common request after a sunny week, storing the last requested data in the cache would ensure that after the first request for an umbrella, every individual who realizes they need an umbrella that rainy day will have a better, more timely fetch experience.

The other common way to create a cache is to find the most commonly requested data.  In some situations, you know the data that is going to be most commonly fetched (you know, for example, that your logo is going to be loaded every time the page loads).  In the above fetches, your cached data would be blueprints for:
Camry
F-150
Model S

This method ensures that necessary data is always going to be present and will not require a request to the database in order to construct the data package.

There are a handful of other optimizations with caching which will be covered in future articles - but one related topic is the extreme optimizations you can make with static resources which you know will always be fetched every time a page loads (think of that logo again).

### Content Delivery Networks (CDN’s) as Car Warehouses
As you can imagine, no matter how quickly you churn out those cars - the further they have to travel on the internet to the end browser, the longer it will take to receive the data.  In the US, most highways have a maximum speed limit of 80 mph, imagine the same is true with sending and receiving data across the internet.  There’s a (relatively) static time speed of transmission and the further they have to travel, the longer it will take for the browser to receive each package sent by the server.  If you open up a website in rural Estonia, if the server your Browser is receiving information from is located all the way in North East Canada, you can expect that website to load substantially slower than if you open up the same site from North East Canada.

The birth of CDN’s came when a savvy group of engineers realized that it is possible to improve the delivery time of those cars by pre-making them and storing them at locations closer to their common requestors.   Companies use CDN’s like Cloudflare, Sucuri, Amazon CloudFront to pre-load their large data packages and store them at locations that are geographically closer to their end users.

This means that the not only is the distance the data has to travel along that road substantially shorter but also that the data packages are less liable to be accosted by pirates (you’re less likely to have errors on receipt).  You increase efficacy and reduce transmission time.

CDN’s can therefore be thought of as data warehouses spread across the globe to improve data transmission.

Analogy: Managing automobile manufacturing relative to basic system design principles

Engineering writing with a systems bias.

Aysnchronous Pancake Delivery in Javascript

Paint by Render

System Design and Cars