Forem: Shwetabh Shekhar

My favorite CLI Tools for improved productivity.

Shwetabh Shekhar — Sun, 23 May 2021 15:22:32 +0000

These are my top 5 favorites. Use them to make working with #terminal easier and efficient. - YMMV

First and foremost, if you are on Mac replace your terminal with iTerm, a much more powerful powerful terminal emulator.

Fishshell: I love the autosuggestions. Saves way too much time. There are many other useful features as well.
thefuck: Misspelled a command? Use this simple command to correct typos. There is no need to retype it.
HomeBrew: Easy installation of apps. On Mac, the cask install feature comes in handy and removes the need to drag applications.
autojump: Forget cd. This is a much faster way to navigate your filesystem. It maintains a database of the directories you use the most from the command line.
TLDR: Concise man pages with lots of examples, just the way we want.

These three books have helped shaped my Developer career.

Shwetabh Shekhar — Mon, 19 Apr 2021 17:03:12 +0000

"Some books are to be tasted, others to be swallowed, and some few to be chewed and digested."

Out of the plethora of books I have read through, these three technical and self-help books, for me, undoubtedly fall into the category of being chewed and digested. Why so? Because they have not only impacted the way I think about work or approach a problem but have helped me add order to my life, write improved code, crack interviews, and achieve a few of my biggest goals - YMMV.

Atomic Habits
Have you ever wondered why solving one leet code question consistently in the long run always works? Why do you keep getting better and better?
It is because of the power of consistent small progress that accumulates to give a positive result. This book helped me realize you don't need to start making drastic changes to become successful. Moreover, techniques such as habit stacking helped me form and maintain new habits easily.
Pragmatic Programmer
I read this during the 2020 lockdown and was saddened to discover it so late. The beautiful thing about this book is that it sparks ideas when you read it. Can you do something more efficiently? Can you do it more elegantly? The topics introduced in this book are a must to put into practice for every developer to empower their career. The tips are equally good.
Cracking the Coding Interview
This book is laden with concise theories and thoughtful questions. Even though there are many online alternatives to it, this has a special place in my heart as it helped me crack the Amazon SDE Intern interview back in 2017 along with many others.

Please share with me books you would say have added value and helped you progress in your career.

Complete Webpage Rendering Process In Browser

Shwetabh Shekhar — Tue, 09 Feb 2021 12:29:34 +0000

I will try to explain the webpage rendering process in a browser in depth.

Once the server supplies the resources (HTML, CSS, JS, images, etc.) to the browser it undergoes the below process:

Parsing - HTML, CSS, JS
Rendering - Construct DOM Tree → Render Tree → Layout of Render Tree → Painting the render tree.

The rendering engine starts getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.
A DOM tree is built out of the broken response.
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files).
At this stage the browser marks the document as interactive and starts parsing scripts that are in "deferred" mode: those that should be executed after the document is parsed. The document state is set to "complete" and a "load" event is fired.
Each CSS file is parsed into a StyleSheet object, where each object contains CSS rules with selectors and objects corresponding to CSS grammar. The tree built is called CSSCOM.
On top of DOM and CSSOM, a rendering tree is created, which is a set of objects to be rendered. Each of the rendering objects contains its corresponding DOM object (or a text block) plus the calculated styles. In other words, the render tree describes the visual representation of a DOM.
After the construction of the render tree it goes through a "layout" process. Which means giving each node the exact coordinates where it should appear on the screen.
The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.
Repaint: When changing element styles that don't affect the element's position on a page (such as background-color, border-color, visibility), the browser just repaints the element again with the new styles applied (that means a "repaint" or "restyle" is happening).
Reflow: When the changes affect document contents or structure, or element position, a reflow (or relayout) happens.

What is the internal structure of a web browser?

To understand the page rendering process explained in the above points we also need to understand the structure of a web browser.

User interface: The user interface includes the address bar, back/forward button, bookmarking menu, etc. Every part of the browser display except the window where you see the requested page.

Browser engine: The browser engine marshals actions between the UI and the rendering engine.

Rendering engine: The rendering engine is responsible for displaying requested content. For example, if the requested content is HTML, the rendering engine parses HTML and CSS and displays the parsed content on the screen.

Networking: The networking handles network calls such as HTTP requests, using different implementations for different platforms behind a platform-independent interface.

UI backend: The UI backend is used for drawing basic widgets like combo boxes and windows. This backend exposes a generic interface that is not platform-specific. Underneath it uses operating system user interface methods.

JavaScript engine: The JavaScript engine is used to parse and execute JavaScript code.

Data storage: The data storage is a persistence layer. The browser may need to save all sorts of data locally, such as cookies. Browsers also support storage mechanisms such as localStorage, IndexedDB, WebSQL, and FileSystem.

Note:
During the rendering process, the graphical computing layers can use a general-purpose CPU or the graphical processor GPU as well.
When using GPU for graphical rendering computations the graphical software layers split the task into multiple pieces, so it can take advantage of GPU's massive parallelism for float point calculations required for the rendering process.

Useful Links:

What strategy do you follow when learning something new?

Shwetabh Shekhar — Tue, 19 Jan 2021 09:10:55 +0000

Do you target it's BREADTH first? Go through different sections on the subject matter in a shallow way and then slowly dive deep into each one.

Or do you do a DEPTH first approach where you finish each section in detail and then only move onto the next?

Generating Meaningful Test Data Using Faker

Shwetabh Shekhar — Sun, 17 Jan 2021 10:49:28 +0000

Whether you are building an API or writing tests for features that process massive datasets, meaningful test data is always a necessity. How do we fill this need? Faker is the answer.

What is Faker?

Faker is a library that can be used to generates a humongous amount of realistic fake data in Node.js and the browser. It is also available in a variety of other languages such as Python, Perl, Ruby, and C#. This article, however, will focus entirely on the Node.js flavor of Faker.

You can see a live demonstration of faker here.

Generating Data using Faker

Let's consider a use case where we want to store personal information in a CSV file with the following fields:

First Name
Last Name
Address(City, State, Zip Code, Country)
Phone Number
Email

And we need 100,000 such records (meaningful). Stop for a moment and think how would you have generated this? This is where Faker comes into play.

Generating CSV Datasets

Initialize your node project and Install faker:

npm i faker

Include the dependencies in your project.

const faker = require('faker');
const fs = require('fs');
const _ = require('lodash');

Define your headers for CSV based on the schema:

//define the headers of your csv file.
//define the object literal that would store the functions for each index
//faker generates new data for every call
let csvHeaders = {
    FIRST_NAME: faker.name.firstName(),
    LAST_NAME: faker.name.lastName(),
    STREET_ADDRESS: faker.address.streetAddress(),
    CITY: faker.address.city(),
    STATE: faker.address.state(),
    ZIP_CODE: faker.address.zipCode(),
    COUNTRY: faker.address.country(),
    VOICE_NUMBER: faker.phone.phoneNumber(),
    EMAIL_ADDRESS: faker.internet.email(),
}

I am using streams, given we are writing input into output sequentially.

// open write stream
let stream = fs.createWriteStream("huge-csv.csv");
// write the header line.
stream.write(Object.keys(csvHeaders).toString()+ "\n");

Create the 100,000 record CSV file.

//write the body
let csvBody = [];
for (let i = 0; i < 1000000; i++) {
    _.forEach(csvHeaders, function(value, key){
        //console.log(value);
        csvBody.push(value);
    })
    //console.log(csvBody.toString(), 'CSV BODY');
    stream.write(csvBody.toString()+ "\n");
    csvBody = [];


}
// close the stream
stream.end();

Generating JSON Datasets

The process of generating the JSON file remains more or less the same with minor tweaks. I will leave that as an exercise. The code is available at my github repository.

Other Features and API Methods of Faker

I have only used a subset of the supported API methods in the above example. The faker.js can generate fake data for various other areas, including commerce, company, date, finance, image, random, etc.

const faker = require('faker');

# Jobs
let jobTitle = faker.name.jobTitle();
console.log(jobTitle);

let jobArea = faker.name.jobArea();
console.log(jobArea);

# dates

let futureDate = faker.date.future();
console.log(futureDate);

let recentDate = faker.date.recent();
console.log(recentDate);

let weekday = faker.date.weekday();
console.log(weekday);

# random values
let number = faker.random.number();
console.log(number);

let uuid = faker.random.uuid();
console.log(uuid);

let word = faker.random.word();
console.log(word);

let words = faker.random.words(6);
console.log(words);

# and so on...

You can even use it directly in the browser as well.

<script src = "faker.js" type = "text/javascript"></script>
<script>
  var randomName = faker.name.findName(); // Caitlyn Kerluke
  var randomEmail = faker.internet.email(); // Rusty@arne.info
  var randomCard = faker.helpers.createCard(); // random contact card containing many properties
</script>

Fake data is extremely useful when building and testing our application and Faker can help us with that. For a complete list of supported APIs, visit this link. Have you used Faker? How was your experience?

When Should You Jump From Your Job?

Shwetabh Shekhar — Fri, 15 Jan 2021 16:11:44 +0000

After you start at a new place:

Every 4 months have a one-on-one meeting with your supervisor. Talk about your progress within the company/agency/group, and voice your support for participation in projects or programs that would be beneficial to your career, or promotions. Let your supervisor know you are interested in challenges.

If you get to a point where your career trajectory at a company/group/whatever is stagnating - THEN you should start looking for another position.

If you're at the same company for a while but you're progressing, there can be advantages - hikes, more money in stock options, higher responsibilities, you get to REALLY know your clients.

If you're in a company and you let them know you're up for challenges or promotions and nothing happens - and you're demonstrating you can handle the harder work - that's a sign to move on.

You are worth more the more you learn. Otherwise, you are getting paid less the more you know.

How AWS Lambda Works Underneath?

Shwetabh Shekhar — Wed, 13 Jan 2021 19:12:52 +0000

_Details create the big picture. - Sanford I. Weill_

AWS Lambda has become ubiquitous when it comes to serverless applications. And why shouldn't it be? Using it you can run code for virtually any type of application or backend service - all with zero administration. There is no need to provision or manage any infrastructure. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. But ever wondered how that happens?

How exactly does Lamda run our code? How does it autoscale? How does it balance the load? How does it handle the errors? What about security? Where does the code exactly run? What exactly happens when you call lambda.invoke()?

Understanding the basic building blocks

To answer all our above questions we need to understand the architecture of AWS Lambda. Under the hood, AWS Lambda has a really sophisticated architecture that keeps on evolving. This is what takes care of all the undifferentiated heavy lifting for the developers. This architecture can be dissected into two parts, Control Plane and Data Plane as depicted below:

Control Plane

This plane is responsible for our interaction with AWS Lambda using various methods such as AWS Console, APIs, and AWS SAM. It is responsible for packaging the code and providing configuration APIs which allows us to set various configurations such as concurrency, environment variables, timeouts amongst other options.

Data Plane

This plane is responsible for handling the synchronous and asynchronous invocation of Lambda. Different components present in it handle authentication, scalability, errors, different limits, etc. To understand how these components work in synergy and make Lambda what it is we first need to understand each and every component of it individually.

Front End Invoke: This service authenticates all lambda invocation requests. Moreover, it is also responsible for loading metadata and coordinating with Counting Service to confirm concurrency. Basically, it orchestrates synchronous and asynchronous invocation of Lambda.

Counting Service: A critical component that provides a region-wide view of customer concurrency to help enforce set limits. It tracks the current concurrency and takes further action when the limit is hit.

Worker Manager: It tracks container idle and busy state and schedules incoming invoke requests to available containers. Moreover, it ensures lambda executes with correct privileges. In addition to that, it interacts with Placement Service to scale containers up and down for scalability.

Placement Service: This is responsible for placing sandboxes for workers. It uses intelligence to help determine where a sandbox should be put and how to administer unhealthy workers.

Worker:

This is where our code executes. Worker Provisions a secure environment for customer code execution. It also provides multiple run time environments. Furthermore, it downloads customer code and mounts it for execution. In addition to that, it also notifies the Worker Manager when execution is completed.

One Worker can have the Lambda function running from various accounts. There are virtualization mechanisms present to handle isolation for codes for the different lambda functions. (More on this in the next tutorial.)

How does everything fit together?

Let's answer our original question What exactly happens when we hit invoke on lambda?

Lambda is invoked. The Application Load Balancer routes the request to a fleet of Front End Invoke service.
Front End Invoke authenticates the request. It then downloads function metadata and goes to the counting service to check the concurrency limit. Upon successful authentication and concurrency validation, it goes to the Worker Manager to reserve a sandbox.
Upon receiving the request, the Worker Manager firstly locates a Worker. It then creates a sandbox on it. Upon successful creation, it downloads the function code and then initializes the run time. It finally calls init on it. [cold start]
Once the init function has completed, the Worker lets the Worker Manager know which lets the Front End Invoke know.
Front End now directly calls Invoke on the Worker.
Once the code finishes execution Worker lets the Worker Manager know it is idle and thus there is a warm sandbox.

Warm Start

We all know Warm start in Lambda's run faster. This is the exact reason why. During a warm start, the Worker Manager doesn't need to administer a worker and initialize it. It already exists and is ready for utilization. Consider the above scenario where the code has just run on a worker and it is warm.

The first three steps remain the same.
Front End reaches to Worker Manager to reserve a sandbox but this time Worker Manager already has a warm sandbox and thus it straightway returns the Worker's location to the Front End Service.
Front End calls invoke on it which is relatively faster.

How does autoscaling work?

What happens when the Worker Manager can't find a Worker for provisioning sandboxes? Such an event occurs when all Workers are utilized and in such a scenario, the Worker Manager interacts with Placement Service which provides it with a new Worker location. Placement service is solely responsible for fulfilling worker capacity and maintaining scalability. Anytime there are no new workers left it provides Worker Manager with new workers(with a lease of 6-10 hrs).

How does it handle failures?

Lambda continuously monitors the health of hosts and removes unhealthy hosts. When a Worker becomes unhealthy Worker Manager detects and stops provisioning sandboxes on it. And if the entire availability zone fails the system components continue working without routing traffic to the failed availability zone. This is how Lambda always remains fault-tolerant.

Conclusion

This is more or less the whole crux of how Lambda works under the hood and executes our code while maintaining scalability and fault tolerance. There is still a lot of questions left unanswered though. How exactly does a Worker work? Moreover, Worker is running functions from various accounts on top of only one hardware then how does it isolate the code and runtime? What is the virtualization technology used? I will be answering all these questions in the next part of this tutorial. Hope this was helpful.

Acknowledgments: All images are part of the AWS reinvent 2018 & 2019 sessions. I strongly suggest watching it. Video 1, Video 2

Browser: Complete Process Of Hitting A URL And Rendering The Page.

Shwetabh Shekhar — Wed, 06 Jan 2021 08:10:26 +0000

Acknowledgments: My post is inspired by the famous what-happens-when GitHub repository.

Ever wondered what happens when you type in an URL in the browser? What happens behind the scenes to fetch the page? How does the page load?

Read on to find out.

You type maps.google.com(Uniform Resource Locator) into the address bar of your browser and press enter.
Every URL has a unique IP address associated with it. The mapping is stored in Name Servers and this procedure is called Domain Name System.
The browser checks its cache to find the IP Address for the URL.
- If it doesn't find it, it checks its OS to find the IP address (gethostname);
- It then checks the router's cache.
- It then checks the ISP's cache. If it is not available there the ISP makes a recursive request to different name servers.
It checks the com name server (we have many name servers such as 'us', 'gov', 'io' etc) and it will redirect to google.com.
google.com's name server will find the matching IP address for maps.google.com in its’ DNS records and return it to your DNS recursor which will send it back to your browser.
Browser initiates a TCP connection with the server. It uses a three-way handshake:
Client machine sends an SYN packet to the server over the internet asking if it is open for new connections.
If the server has open ports that can accept and initiate new connections, it’ll respond with an ACKnowledgment of the SYN packet using an SYN/ACK packet.
The client will receive the SYN/ACK packet from the server and will acknowledge it by sending an ACK packet. Then a TCP connection is established for data transmission!
The browser will send a GET request asking for a maps.google.com web page. If you’re entering credentials or submitting a form this could be a POST request.
The server sends the response.
Once the server supplies the resources (HTML, CSS, JS, images, etc.) to the browser it undergoes the below process: Parsing - HTML, CSS, JS Rendering - Construct DOM Tree → Render Tree → Layout of Render Tree → Painting the render tree
The rendering engine starts getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.
A DOM tree is built out of the broken response.
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files).
At this stage the browser marks the document as interactive and starts parsing scripts that are in "deferred" mode: those that should be executed after the document is parsed. The document state is set to "complete" and a "load" event is fired.
Each CSS file is parsed into a StyleSheet object, where each object contains CSS rules with selectors and objects corresponding CSS grammar. The tree built is called CSSCOM.
On top of DOM and CSSOM, a rendering tree is created, which is a set of objects to be rendered. Each of the rendering objects contains its corresponding DOM object (or a text block) plus the calculated styles. In other words, the render tree describes the visual representation of a DOM.
After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen.
The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.
Repaint: When changing element styles that don't affect the element's position on a page (such as background-color, border-color, visibility), the browser just repaints the element again with the new styles applied (that means a "repaint" or "restyle" is happening).
Reflow: When the changes affect document contents or structure, or element position, a reflow (or relayout) happens.

Clean Off Your Dirt

Shwetabh Shekhar — Tue, 29 Dec 2020 16:16:53 +0000

Here's a short true story.

In the temple of Wat Traimit, Bangkok, Thailand there's a statue of Buddha, solid gold, 10.5 ft high, weighs around 5.5 tons. They used to think it was made of clay. The monastery used to be somewhere else and in 1957 they had to relocate it because of a highway development through Bangkok.

When the crane came to lift it, the idol was so heavy that it began to crack so they put it back down, covered it in a tarpaulin so it wouldn't get wet, and decided to try again the next day.

During the night the abbot came out to look at it, check it wasn't getting wet or damaged. He noticed something gleaming behind the crack and decided to take a closer look. They started to chip the clay away and ended up with a 10.5 ft high solid gold Buddha.

Turns out that hundreds of years before Thailand (Siam as was) was invaded by Burma and the monks of that time covered the Buddha in clay so it wasn't looted. They were all killed by the Burmese along with many others. No-one who knew the secret was left so the golden reality remained intact but hidden. It was finally rediscovered hundreds of years later.

Why tell this story here, now?

Because hidden inside, smothered by the accumulated mental dirt caused by years of disappointments, failures, rejections, regrets is a precious, valuable better you. The you who has creativity, concentration, patience, resolve, purpose, and a million other virtues. All you have to do is clean off the dirt.

Christmas Tree using Python

Shwetabh Shekhar — Sun, 27 Dec 2020 14:09:00 +0000

Merry Christmas Dev community. Here is a simple Christmas tree using Python.

# Christmas Tree in Python
for i in range(10):
    print(''.join(['.'] * (9 - i) + ['^'] * (1 + i * 2) + ['.'] * (9 - i)))
else:
    print(''.join(['-'] * 8 + ['| |'] + ['-'] * 8))

'''
                .........^.........
                ........^^^........
                .......^^^^^.......
                ......^^^^^^^......
                .....^^^^^^^^^.....
                ....^^^^^^^^^^^....
                ...^^^^^^^^^^^^^...
                ..^^^^^^^^^^^^^^^..
                .^^^^^^^^^^^^^^^^^.
                ^^^^^^^^^^^^^^^^^^^
                --------| |--------
          Merry Christmas to all of you. @shwetabh1
'''

There is no use of the else clause but I have used it deliberately, to expose it to devs who are yet not aware of it.

The else clause executes after the loop completes normally. It is useful in cases when we break from a loop. You can read more about it here.

seal vs freeze vs preventExtenstions in JS.

Shwetabh Shekhar — Mon, 07 Dec 2020 17:10:33 +0000

Object.seal(), Object.freeze() and Object.preventExtensions() are popular methods in javascript to render an object immutable. But what are the differences between each of them and when should you prefer one over the other?

Let's try to understand the differences and use cases in detail.

Object.preventExtensions()

This method prevents an object from having new properties added to it, but otherwise leave the rest of the object properties alone.

You are allowed to:

Modify existing values of an object.
Delete existing properties of an object.
Configure existing properties of an object.

You are not allowed to:

Add new properties to an object.

let virus = {
    name: 'SARS-CoV-2' 
}

Object.preventExtensions(virus);

/* ❌ Not Allowed ❌ */
// You can't add new properties.
virus.year = 2020;
virus.year; // undefined. In strict mode, it throws a TypeError

/* ☑️ Allowed ☑️ */
// You can still modify existing values.
virus.name = 'Corona Virus' 

// You can still configure existing properties. 
Object.defineProperty( virus, 'name', { 
    writable: false,
    enumerable: false,
    configurable: false
});

// You can still deleting existing properties.
delete virus.name 

// Use Object.isExtensible() to check if an object is extensible.
Object.isExtensible(virus) //false

Object.seal()

It creates a "sealed" object, which means apart from not being extended, you also can not reconfigure or delete any existing properties

You are allowed to:

Modify existing values of an object.

You are not allowed to:

Add new properties to an object.
Delete existing properties of an object.
Configure the existing properties of an object.

let virus = {
    name: 'SARS-CoV-2' 
}
Object.seal(virus);

/* ❌ Not Allowed ❌ */
// You can't add new properties.
virus.year = 2020;
virus.year; // undefined. In strict mode, it throws a TypeError

// You can't reconfigure existing properties.
Object.defineProperty( virus, 'name', { 
    writable: false,
    configurable: false
}); // fails

// You can't deleting existing properties.
delete virus.name // fails

/* ☑️ Allowed ☑️ */
// You can still modify existing properties values.
virus.name = 'Corona Virus'

// Use Object.isSealed() to check if an object is sealed.
Object.isSealed(virus) // true

Object.freeze()

It creates a "frozen" object which is the highest level of immutability. A frozen object can no longer be changed. What it essentially means is you can not change the object in any way:

You are not allowed to:

Add new properties to an object.
Delete existing properties of an object.
Configure the existing properties of an object.
Modify the existing values of an object.

let virus = {
    name: 'SARS-CoV-2' 
}
Object.freeze(virus);

/* ❌ Not Allowed ❌ */
// You can't add new properties.
virus.year = 2020;
virus.year; // undefined. In strict mode, it throws a TypeError

// You can't configure existing properties. 
Object.defineProperty( virus, 'name', { 
    writable: false,
    enumerbale: false,
    configurable: false
}); // fails

// You can't delete existing properties.
delete virus.name // fails

// You can't modify existing property values.
virus.name = 'Corona Virus' // fails

// Use Object.isFrozen() to check if an object is frozen.
Object.isFrozen(virus) // true

Summary

I have created this table which highlights the differences concisely.

Event Loop and Single Thread Mechanism in JavaScript.

Shwetabh Shekhar — Sun, 06 Dec 2020 06:14:25 +0000

"JavaScript is a single-threaded, non-blocking, asynchronous, concurrent language."

Any Javascript book/tutorial has this line etched in their introduction. On top of that this compact line is perplexing. How exactly is Javascript single-threaded? If so, how does it handle multiple API calls? Isn't Javascript synchronous? Then, how does it perform asynchronous execution? How is Javascript concurrent?

Here is my attempt to answer all these questions and explain how exactly the single thread mechanism works. Let's first try to understand the technical jargon thrown at us in the introductory line.

Single Thread

If a language is single-threaded it signifies, it has only one execution context or thread. What it essentially means is at most one of the blocking functions can execute at a time.

Non-Blocking

In a non-blocking language, the execution never stops or blocked.

Asynchronous and Synchronous Execution

When you execute something synchronously, you wait for it to finish before moving on to another task. Javascript is actually synchronous but it can be manipulated to behave in an asynchronous way.

Concurrent Execution

Concurrency basically signifies the execution of a multitude of tasks over a period of time which JS is very well capable of.

How does everything fit together?

Now that we have those technicalities out of our way let's try to understand how everything fits together. Consider the following code snippet:

console.log('before');
setTimeout(()=> {
    console.log('Inside SetTimeout');
},3000)
console.log('after');

Mull it over and try to figure out its execution flow. Since Javascript is single-threaded, does it wait 3 seconds at setTimeout() and then move to console.log()? We all know that is not the case. Then how does it work? It all is taken care of by the Javascript engine model depicted below:

Image credits:

Memory Heap: This is where the memory allocation happens.
Call Stack: This is where your stack frames are as your code executes. It records where we are in the program. Each entry into the stack is called a stack frame.
Web API: They are not provided by the engine but the Browser (like the DOM, AJAX, setTimeout)
Callback queue: Once the Web APIs have executed they are moved to the callback queue.
Event Loop: When there is no stack frame it moves the result to the stack.

Code Execution Flow

The above model is what makes Javascript tick. Any blocking task is passed on to the Web APIs for execution. Once it completes it is moved to callback queue in the order their execution was finished. Once the Call Stack is empty the event loop moves the output to call stack. This is how Javascript remains always non-blocking as execution is just moved to Web APIs.

Here is the line by line execution flow for the above example:

First-line console.log() goes into the call stack and then executes.
Execution moves to the second line. It is executed asynchronously. SetTimeout is passed to the web APIs and then once the task is completed it is moved to the Callback Queue.
While the above process is happening the third line executes.
The call stack is now empty. The event loop moves th e setTimeout output from the callback queue to the stack.

The above model is what makes Javascript very powerful. It provides it with excellent concurrency and the ability to handle asynchronous calls.

PS: This video by Philip Roberts is by far the best resource out there to understand this in more detail.