Forem: Sanjeev Sharma

CORS, Preflight Requests, and Common Cross-Origin Issues

Sanjeev Sharma — Fri, 28 Feb 2025 19:44:07 +0000

If you've been developing web apps for a while, there's a 99% chance you've encountered a CORS issue at least once. If you're a beginner, you probably found a one-line fix by Googling the exact error and moved on with your task. Today, with AI tools, you don’t even have to leave your IDE to get a solution.

But did you truly understand what the fix did? Why did the issue occur in the first place? If not, I promise that by the end of this post, you will.

Let’s dive in! 💪

What is CORS?

CORS, or Cross-Origin Resource Sharing, is a browser mechanism that restricts frontend code from making cross-origin requests. It’s not an issue per se but a security feature designed to protect users and websites.

The error you encounter typically occurs when your frontend and backend are deployed on separate domains (or subdomains).

In the example above, frontendcamp.in makes a request to api.dev.to. If api.dev.to doesn’t explicitly allow requests from other origins, the browser will block the request.

Why do browsers do that?
Browsers enforce the SOP or Same-Origin Policy, which dictates how a document or script from one origin can interact with resources on another. This prevents malicious websites from executing code on your site.

Two origins are considered the same if the protocol, port (if specified), and host match.

How to fix this issue?
To resolve this, the server must explicitly allow requests from the frontend’s origin.

For example, in the illustration above, api.dev.to should permit www.frontendcamp.in to access its resources.

This can done by adding the following response header.

Access-Control-Allow-Origin: https://www.frontendcamp.in

This header informs the browser that www.frontendcamp.in is authorized to access the resource.

Some developers use * as the header value, allowing requests from any origin. Avoid this unless you have a valid reason for doing so.

An alternate solution
You can’t always modify response headers. For instance, when requesting data from an external service, the above solution won’t work.

In such cases, a proxy server can be used.

This works because CORS is enforced only by browsers. With a proxy server in place, the browser perceives the request as originating from the same domain.

Preflight Requests

A preflight request is a CORS request that the browser automatically sends before the actual request when a cross-origin request is not simple.

It uses the OPTIONS method and includes up to three headers: Access-Control-Request-Method, Origin, and optionally, Access-Control-Request-Headers.

What kind of requests are not considered simple?
A request requires a preflight if it meets any of the following conditions:

It uses an HTTP method other than GET, POST, or HEAD.
It includes custom headers, such as Authorization or X-Registered-With.
It sends data in formats other than application/x-www-form-urlencoded, multipart/form-data, or text/plain.

For example, if frontendcamp.in makes a DELETE request to api.dev.to, the request flow would be:

A preflight request is sent.

OPTIONS /v1/posts/224
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: x-requested-with
Origin: https://frontendcamp.in

The server responds with the applicable CORS policy.

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://frontendcamp.in
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, X-Registered-With
Access-Control-Max-Age: 86400

Access-Control-Allow-Origin: Allows requests from frontendcamp.in
Access-Control-Allow-Methods: Specifies allowed HTTP methods
Access-Control-Allow-Headers: Lists allowed custom headers
Access-Control-Max-Age: Tells the browser how long to cache the preflight response (in seconds)

The actual request is made.

Preflight requests can introduce performance overhead. To mitigate this, it's important to set the Access-Control-Max-Age header to leverage browser caching.

Common CORS Issues

The knowledge you've gained so far should be enough to debug most CORS-related issues.

Now, let's go through some common scenarios.

❗ No 'Access-Control-Allow-Origin' header in response

Access to fetch at 'https://api.dev.to/data' from origin 'https://frontendcamp.in' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Cause

The API does not send the Access-Control-Allow-Origin header.
The browser blocks the request because it doesn't see explicit permission.

Fix
Modify the API response to include Access-Control-Allow-Origin header.

❗ The Request requires Preflight, but the Server doesn’t handle OPTIONS

Access to fetch at 'https://api.dev.to/data' from origin 'https://frontendcamp.in' has been blocked by CORS policy:
Response to preflight request doesn't pass access control check: The server does not respond to OPTIONS requests.

Cause

The API does not handle OPTIONS requests, which are sent as preflight before the actual request.
This happens when using PUT, DELETE, or custom headers (Authorization, X-Requested-With).

Fix
Enable handling for OPTIONS requests on the server.

❗ The API allows a specific Origin, but the Frontend uses a different one

Access to fetch at 'https://api.dev.to/data' from origin 'https://sub.frontendcamp.in' has been blocked by CORS policy:
The 'Access-Control-Allow-Origin' header does not match the request origin.

Cause

The backend only allows https://frontendcamp.in, but the request comes from https://sub.frontendcamp.in.
Many sites use subdomains, and they are treated as separate origins.

Fix
Whitelist the subdomain too.

❗ Credentialed requests (withCredentials: true) not working

Access to fetch at 'https://api.dev.to/data' from origin 'https://frontendcamp.in' has been blocked by CORS policy:
The value of the 'Access-Control-Allow-Origin' header in the response must not be '*'
when the request’s credentials mode is 'include'.

Cause

The request includes credentials (cookies, authentication tokens, etc.), but the server is allowing * as Access-Control-Allow-Origin.
When using credentials, * is not allowed — the API must explicitly list allowed origins.

Fix
Allow credentials & set a specific origin.

Summary

Cross-Origin Resource Sharing (CORS) is a browser security mechanism that restricts frontend code from making cross-origin requests. It’s not an error but a safeguard.
Browsers enforce the Same-Origin Policy (SOP) to prevent malicious websites from accessing resources on other domains.
The server must explicitly allow cross-origin requests by setting the Access-Control-Allow-Origin header with the frontend’s origin.
Using * allows any website to access the resource, which can be a security risk. It should only be used when absolutely necessary.
If you're requesting data from a third-party API and can’t modify its response headers, a proxy server can bypass CORS restrictions.
When a request is not simple, the browser sends an OPTIONS request before the actual request to check if the server allows it.
Requests that use methods other than GET, POST, or HEAD, include custom headers (e.g., Authorization), or send non-standard content types are said to be not "simple".
Frequent preflight requests can cause overhead. Setting the Access-Control-Max-Age header allows the browser to cache the response and improve performance.

Thank you for reading my post. 🙏 I hope you liked it.

Preparing for Frontend interviews?

👉 Check out Frontend Camp

Popular interview questions
Popular frontend system design questions (upcoming)
All for free! ✨

Join now! 🚀

Event Delegation Pattern

Sanjeev Sharma — Tue, 21 Jan 2025 15:24:22 +0000

Event delegation is a design pattern in JavaScript used to efficiently handle events on multiple child elements by adding a single event handler to a common ancestor element. When used correctly, this pattern can significantly improve performance.

Consider the following HTML structure:

The parent element is a div with the id of container, and it contains multiple button elements as its children. Traditionally, if we wanted to trigger a function when any button is clicked, we would attach a separate click event handler to each button.

Event delegation takes a different approach. Instead of attaching multiple event handlers, we attach a single event handler to the parent element (i.e., the container). Within the parent element's event handler function, we can identify the specific child element that triggered the event.

But how does this work?

It’s possible because of event bubbling. Most events in the DOM bubble up from the target element (where the event occurred) to the root DOM node. This allows the parent element to listen for events triggered by its child elements.

If you'd like to dive deeper into event bubbling and capturing, check out this detailed explanation.

/*
 * <div id="container">
 *   <button>Item 1</button>
 *   <button>Item 2</button>
 *   <button>Item 3</button>
 *   <button>Item 4</button>
 *   <button>Item 5</button>
 *   <button>Item 6</button>
 *   <button>Item 7</button>
 *   <button>Item 8</button>
 *   <button>Item 9</button>
 * </div>
 */

const container = document.querySelector("#container");

container.addEventListener("click", function (event) {
  console.log(event.target); // gives the element that triggered the event
  console.log(event.target.textContent); // Item 5
});

When Item 5 is clicked, the event from the button bubbles up, and we intercept it in the container's event handler. The event.target property provides a reference to the specific element that triggered the event.

Benefits of Event Delegation

Efficiency: No matter how many child elements we have — even thousands — we only use a single event handler. This approach conserves memory.
Dynamic Elements: When elements are added or removed dynamically, we don't need to manually add or remove event listeners for those elements.

Common Pitfalls

Be mindful of event types: Events such as blur, focus, and mouseenter do not bubble up, so event delegation cannot be used for handling them.
Ensure the correct target element: Always validate the target element to avoid triggering unintended actions.
Complex logic: While this approach is efficient, managing all events in a single handler can become complex if the logic isn’t well-structured.

React delegates all events to the root node by default. Even if you add multiple onClick handlers to child elements, React does not attach event listeners directly to those child DOM elements. Instead, it uses a Synthetic Event System, which normalizes event behavior across browsers and efficiently manages events through event delegation.

Summary

Event delegation is a JavaScript design pattern that optimizes event handling by attaching a single event listener to a common ancestor element instead of adding listeners to multiple child elements.
It relies on event bubbling, where events propagate from the target element to parent elements up to the root DOM node.
It reduces memory usage by using a single event handler regardless of the number of child elements and automatically handles dynamically added or removed child elements without requiring additional event listeners.
Certain events, such as blur, focus, and mouseenter, do not bubble up and cannot be delegated.
React uses event delegation by default, attaching all event listeners to the root node via its Synthetic Event System.

Preparing for Frontend interviews?

👉 Check out Frontend Camp

Popular interview questions
Popular frontend system design questions (upcoming)
All for free! ✨

Join now! 🚀

Watch my dev vlogs here: YouTube 🎥

10 Backend Terms Every Frontend Developer Should Know

Sanjeev Sharma — Thu, 09 Jan 2025 21:09:19 +0000

When a backend dev gives their update in the daily standup meeting, most frontend devs are clueless about the work they're doing. They use a lot of jargons that sound gibberish to us frontend devs. But not anymore! 😎

This post aims to tackle some of those jargons. Why should you learn these, you ask? First, you’ll start to understand your product's architecture a bit more. Second, don’t limit yourself to frontend — being an engineer means having a well-rounded understanding of other domains too.

Remember, backend devs aren’t trying to confuse anyone — they’re just speaking the language of their domain. Let’s break it down into simpler terms and demystify concepts like rate limiting, load balancing, proxies, and many more.

Ready? Let’s dive in! 💪

1. Rate Limiting

Rate limiting is a way to control the number of requests a client (like a user, app, or system) can make to a server within a specific period. Think of it as a traffic cop ensuring no one overuses or abuses the server's resources.

For example, a server may allow 100 requests per minute from a single client. If the client exceeds this limit, the server will reject additional requests, often with a 429 (Too Many Requests) response.

Usage of Rate Limiting:

Prevent Abuse and Overload: Rate limiting ensures no single user or system overwhelms the server by sending excessive requests, which could crash the server.
Control Costs: Helps avoid unexpectedly high resource usage (like bandwidth or compute power), which can be costly. For instance, limiting API calls to a free-tier user's account to avoid excessive use without payment.
Enhance Security: Helps mitigate attacks like DDoS (Distributed Denial-of-Service) by blocking excessive requests from attackers.

2. Load Balancing

Load balancing is a way to distribute incoming requests or traffic across multiple servers to ensure no single server gets overwhelmed. Think of it as a traffic cop directing cars (requests) to different lanes (servers) to keep everything running smoothly.

For example, Social media platforms like Instagram have millions of users accessing its servers simultaneously. Instead of sending all those users to one server, a load balancer ensures their requests are spread across several servers.

Usage of Load Balancing:

Avoid Overloading Servers: If all traffic goes to one server, it might crash due to excessive load. Load balancing prevents this by distributing requests evenly.
Improve Performance and Speed: By spreading traffic, each server handles a manageable number of requests, leading to faster responses for users.
Scale Applications: As traffic increases, you can add more servers to the pool, and the load balancer will automatically start distributing traffic to the new servers.
Ensure High Availability: If one server fails, the load balancer redirects traffic to the other working servers, ensuring the website or service stays online.

3. Caching

Caching is a way to store frequently accessed data temporarily so that it can be retrieved quickly without repeatedly fetching it from the original source.

Think of it like keeping a frequently used recipe on your kitchen counter. Instead of searching for it in a cookbook every time you need it, you grab it from the counter, saving time and effort.

Most backend systems use Caching for storing frequently used database query results, API responses, or pre-rendered web pages. Redis is popular choice among backend developers for caching data.

Usage of Caching:

Speed Up Performance: Fetching data from a cache is much faster than getting it from the original source (e.g., a database or server).
Reduce Load on Servers: By serving data from the cache, you reduce the number of requests to the backend, preventing it from being overwhelmed.
Handle High Traffic: During peak usage, caching helps ensure the system can handle many users without slowing down.

4. CDN

A CDN (Content Delivery Network) is a network of servers distributed across different locations that work together to deliver content to users more quickly. It helps speed up the process of loading websites, images, videos, and other content by serving them from a server that is geographically closer to the user.

Imagine a library with books stored in different branches. Instead of always going to the central library to get a book, you can visit the closest branch and get the book faster. A CDN does something similar by storing copies of website content in multiple locations.

Usage of CDN:

Faster Load Times: By serving content from a server closer to the user, a CDN reduces the distance data has to travel, leading to faster load times.
Better Scalability and Reliability: CDNs make it easier for websites to scale by automatically handling a large number of users. If one server goes down, CDNs can route the traffic to another server without affecting the user experience.

5. Microservices

Microservices is an architectural style where an application is divided into smaller, independent services, each responsible for a specific piece of functionality. Each microservice is like a small building block that focuses on one task and communicates with other services to create the full application.

Imagine a company where each department (sales, marketing, finance, etc.) works independently but collaborates to run the business. Similarly, in a microservices architecture, each service (like user management, payment processing, etc.) works on its own but interacts with others to make the whole system work.

The opposite of Microservices is Monolithic architecture, where all the functionality of an application is combined into a single, unified service or codebase.

Usage of Microservices:

Scalability: Since each service is independent, you can scale them individually. For example, if the payment processing service gets more traffic, you can scale just that service without affecting the others.
Flexibility and Technology Choices: Each microservice can be built with a different technology stack, allowing teams to choose the best tool for each job. For example, You could use Python for data analytics and Node.js for real-time chat without worrying about compatibility.

6. API Gateway

An API Gateway is a server that acts as an entry point for all client requests to your system. It routes those requests to the appropriate microservice, handles load balancing, authentication, caching, and other tasks. In simple terms, it’s like a doorman who directs visitors to the right department in a large building.

Imagine a large organization with many departments (microservices), and instead of going directly to each department, visitors (users) go through a central reception (API Gateway) that sends them to the right place.

Kong is a popular open-source API gateway used by backend developers.

Usage of API Gateway:

Single Entry Point: It simplifies the interaction between clients and the backend services by providing a single entry point for all requests, rather than having clients talk to multiple microservices directly. The API Gateway directs requests to the correct microservice based on the URL, method, or other factors, acting as a traffic controller.
Logging and Monitoring: It collects logs and metrics for all requests passing through, helping to monitor the system and debug issues.
Security: It rate limits, load balances and check for authentication token in incoming requests.

7. Webhook

A Webhook is a way for one application to send real-time updates or notifications to another application when a specific event happens. Instead of the receiving application repeatedly checking for updates (polling), the sending application automatically sends the information when needed.

For example, when something important happens (like a package delivery), the sender (delivery service) texts you (the recipient) immediately, instead of you having to constantly check the website for updates.

Usage of Webhooks:

Real-Time Notifications: Webhooks provide instant updates, eliminating delays caused by periodic polling.
Automation: Webhooks enable automatic workflows between different applications or systems.

8. Sharding

Sharding is a method of splitting a large database into smaller, more manageable pieces, called shards. Each shard holds a portion of the data and operates as an independent database.

Think of sharding as dividing a library's books into multiple sections based on genres. Instead of searching the entire library for a book, you only look in the relevant section, making the process faster and more efficient.

Usage of Sharding:

Improved Performance: By dividing data across multiple shards, the workload is distributed. This reduces the load on any single database and allows queries to be processed faster.
High Availability: If one shard goes down, only a portion of the data is affected. The rest of the system continues to work, making it more resilient.

9. Proxy

A Proxy is a server that acts as an intermediary between a client (like your browser) and another server (like a website). Instead of connecting directly to the server, your request goes through the proxy, which forwards it to the destination and then sends the response back to you.

Think of it like a middleman: if you want to send a message to someone, you give it to the middleman, who delivers it for you and brings back the reply.

Usage of Proxy servers:

Privacy and Anonymity: A proxy hides your identity by masking your IP address. The destination server only sees the proxy's IP, not yours.
Bypassing Restrictions: Proxies allow users to access content that might be blocked in their region by routing requests through a server in a different location.

10. Message Queues

A Message Queue is a system used to send, store, and retrieve messages between different parts of an application (or between applications) in a reliable and organized way. Instead of sending messages directly, a queue acts like a post office:

One part of the system (the sender) places a message in the queue.
Another part (the receiver) picks it up whenever it’s ready to process it.

RabbitMQ and Apache Kafka are two popular message queue systems,

Usage of Message Queues:

Decoupling Systems: A message queue allows different parts of a system to work independently. The sender and receiver don’t need to know about each other or work at the same time.
Asynchronous Processing: Message queues enable background tasks to be handled without making the user wait. For example, When you upload a photo, the app instantly confirms the upload while processing resizing and optimization tasks in the background.

Thank you for reading my post! 🙏 I hope you've learnt something today.

Please leave a reaction 🦄 or a comment 💬, so this post reaches other devs like you. 🌱👨‍💻

Preparing for Frontend interviews?

👉 Check out Frontend Camp

Popular interview questions
Popular frontend system design questions (upcoming)
All for free! ✨

Join now! 🚀

Check out the interview series on DEV!

Event Flow: Bubbling & Capturing

Sanjeev Sharma — Wed, 08 Jan 2025 16:33:31 +0000

This is post #7 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider joining Frontend Camp 💚.

Event bubbling and capturing, both are propagation mechanisms in DOM(Document Object Model). Both these mechanisms are opposite of each other.

Event Bubbling

In Event bubbling, the event, after triggering the handler on the target element(event.target) propagates upwards(bubbles) to the root element of the document. On its way it triggers all the event handlers on the parent elements.

/*
<div id="container">
  Hello world!
  <button id="btn">Click me</div>
</div>
*/

const container = document.getElementById('container');
container.addEventListener('click', function(event) {
  console.log('Container handler!');
});

const btn = document.getElementById('btn');
btn.addEventListener('click', function(event) {
  console.log('Button handler!');
});

In the snippet above, when you click the button you'll see the following output in console:

"Button handler"
"Container handler"

First the handler on the button is called and the event.target property is set to button as it initiated the event. Event on its way up to the root element, it calls its parent's event handler.

Almost all events bubble but there are a few exceptions like focus event that do not bubble.

You can stop bubbling by calling the stopPropagation() method on the event. If the button's event handler in the above snippet stops propagation, the container's event handler won't be called.

btn.addEventListener('click', function(event) {
  console.log('Button handler!');

  // ancestor elements won't receive the event
  event.stopPropagation();
});

You can access the element that initiated the event by accessing target.event property. Also, the element whose handler is being executed can be accessed using event.currentTarget.

container.addEventListener('click', function(event) {
  console.log('Container handler!'); // 'Container handler!'
  console.log(event.target); // btn
  console.log(event.currentTarget); // container
  console.log(this); // container
});

Want to learn more about the this keyword? I wrote a post on it.

Event Capturing

We've only been seeing half the picture until now. When the button in the above snippet is clicked, it isn't the first element to receive that event. 👀

The event flow consists of three phases:

Capturing phase: The event flows from the root element to the target element.
Target phase: The event is received on the target element.
Bubbling phase: The event starts propagating back to the root element.

By default, all event handlers are only called during target and bubbling phase. To call event handlers in the capturing phase, pass true as the third argument.

el.addEventListener('click', () => {}, true);
// or to be more explicit
el.addEventListener('click', () => {}, { capture: true });

If you are using a handler in capturing phase, it won't be called in the bubbling phase.

Similar to bubbling, when event.stopPropagation() is called during the capturing phase it won't let the event flow further i.e. down the DOM, in this case.

In the snippet we discussed earlier, if container stops propagation during capturing phase, the button's handler will never be called.

/*
<div id="container">
  Hello world!
  <button id="btn">Click me</div>
</div>
*/

const container = document.getElementById('container');
container.addEventListener('click', function(event) {
  console.log('Container handler!');
  event.stopPropagation();
}, true); // capturing phase

const btn = document.getElementById('btn');
btn.addEventListener('click', function(event) {
  // this will never be logged
  console.log('Button handler!');
});

This is why you should always have a good reason to use event.stopPropagation(). It can lead to unexpected issues that are hard to debug in a complex or deeply nested DOM tree.

Event capturing is rarely used compared to Bubbling. Bubbling has a lot of use cases like "Event delegation" - an important performance pattern.

This post lays down the foundation for the next topic - Event delegation. Make sure you understand it well. Have doubts? Leave them in the comments. ✌️

Summary

Event flow consists of three phases: Capturing, Target and Bubbling phase.
In the capturing phase, event flows down from the root element to the target(event.target) element.
In the bubbling phase, event flows from the target element to the root element.
By default, all event handlers are called only during target and bubbling phase.
By passing a third argument in the addEventListener function, you can set the handler on the capturing phase.
At any point in the event flow, calling event.stopPropagation() will stop the event from flowing further.

Like what you just read? 👉 Consider joining the waitlist on Frontend Camp.

Leave some reactions "🦄" and comments so this post helps other devs like you. 🙏

Cookies, Local storage and Session storage

Sanjeev Sharma — Sun, 05 Jan 2025 06:06:29 +0000

This is post #6 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider signing up on Frontend Camp.

Cookies, Local Storage, and Session Storage are all used to store data on the client side. These mechanisms are particularly useful for storing authentication tokens or client-only states, such as themes or personalized settings. All three storage types share the following characteristics:

They store data as key-value pairs.
All values are stored in string format. If a value is not a string, it is serialized before being stored.
Data stored in these mechanisms is accessible to the client (except for HttpOnly cookies).

Cookies

Cookies cannot store large amounts of data; their storage is capped at approximately 4KB per domain. This limitation exists because cookies are automatically sent to the server with every request made by the browser. Storing excessive client-side data in cookies would increase the payload size, negatively impacting performance.

What kind of data should we store in Cookies?
Cookies are ideal for storing data that needs to be transmitted to the server, such as authentication tokens, session IDs, analytics IDs, and similar information. Additionally, cookies allow data sharing across different tabs or windows of the same domain or subdomain.

You can configure cookies using various flags to tweak their behavior or enforce security:

HttpOnly ensures cookies are inaccessible via JavaScript on the client side, mitigating the risk of XSS attacks.
maxAge/expires specifies an expiry date for the cookie. If no expiry date is set, the cookie is deleted when the browser is closed.

Want to learn more about cookie flags? Check out my LinkedIn post.

Unlike local storage and session storage, cookies can also be set (read: "added") by the server using the Set-Cookie header.

// Set a cookie for the key `token` that `expires` on 1st March 2025.
document.cookie =
  'token=a1-b2-c3; expires=Sat, 1 Mar 2025 23:59:59 GMT; path=/';

// Read all cookies. There's no way to read specific cookies using `document.cookie`.
// You have to parse the string yourself.
console.log(document.cookie); // token=a1-b2-c3

// Delete the cookie with the key `token` by setting an
// expiry date in the past. The value doesn't matter.
document.cookie = 'token=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';

Local storage

Unlike cookies, localStorage offers a significantly larger storage capacity of approximately 5MB per domain. This is because localStorage is designed for storing long-term data. It retains data even when the browser is closed, making it ideal for persistent client-side storage needs.

What kind of data should we store in localStorage then?
localStorage is best suited for storing data that is used only on the client side and does not need to be sent to the server with every request. Some examples are the theme of a website or products added in cart before a used has signed in.

Data stored in localStorage persists indefinitely until the user deletes it manually or the website clears it using JavaScript.

Similar to cookies, data in localStorage is accessible across all tabs or windows of the same origin, making it useful for sharing client-side state within a domain.

// Set a value in localStorage.
localStorage.setItem('theme', 'dark');

// Get a value from localStorage.
console.log(localStorage.getItem('theme')); // 'dark'

// Remove a value from localStorage.
localStorage.removeItem('theme');

// Clear all data in localStorage.
localStorage.clear();

Session storage

sessionStorage is used to store short-lived, client side data. Like localStorage, it provides a storage capacity of around 5MB per domain and shares the same API.

While both sessionStorage and localStorage share similar functionalities, they differ in two key aspects: Data persistence and Accessibility.
Unlike localStorage, sessionStorage does not retain data once the tab or browser is closed. Additionally, data stored in sessionStorage is isolated to the specific tab or window where it was created, meaning other tabs or windows from the same origin cannot access it.

What's the use case for sessionStorage then?
sessionStorage is ideal for storing data that is needed only for a single session. For instance, consider a user filling out a long form who accidentally refreshes the page. If the form data is stored in sessionStorage, it will persist through the refresh, allowing the user to continue without losing their progress.

However, it's important to note that this data will not be accessible in a different tab or once the tab is closed.

// Set a value in sessionStorage.
sessionStorage.setItem('username', 'johndoe');

// Get a value from sessionStorage.
console.log(sessionStorage.getItem('username')); // 'johndoe'

// Remove a value from sessionStorage.
sessionStorage.removeItem('username');

// Clear all data in sessionStorage.
sessionStorage.clear();

While cookies are automatically included in every request sent by the browser, data stored in localStorage or sessionStorage can be manually transmitted to the server by writing custom code.

Summary

Cookies, localStorage and sessionStorage are used to store data on client side.
Cookies are the only form of storage which can be set by the server too using Set-Cookie response header.
Cookies are automatically sent to the server with every request.
localStorage and sessionStorage have a significantly large storage(5MB) compared to the cookies(4KB). Both of these storages share the same API interface.
Cookies have an expiry date, if not, they are cleared when the browser is closed.
localStorage data persists indefinitely unless manually cleared by the user or the website itself.
sessionStorage data is cleared after the session ends i.e. when the tab or the window is closed.

Like what you just read? Consider checking out Frontend Camp ✌️

`this` in JavaScript Explained

Sanjeev Sharma — Tue, 24 Dec 2024 17:26:51 +0000

This is question #5 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider signing up on Frontend Camp.

The this keyword always refers to the current context of a function or script.

this is a confusing topic for most of us (pun intended), but it doesn't have to be. All you need to do is remember some rules.

Following rules, in order of precedence, dictate how value of this is determined during runtime:

Usage in a Function constructor

If a function is called with the new keyword, this inside the function refers to the newly created object instance.

function Book(title) {
  console.log(this);
  this.title = title;
  console.log(this);
}

const book1 = new Book('Jungle Book');

// {}
// { title: "'Jungle Book' }"

console.log(book1.title); // 'Jungle Book'

Explicitly binding `this`

call(), apply() or bind() can be used to explicitly set the value of this inside a function.

call() and apply() are used when a function needs to be invoked immediately.
bind() returns a new function to be used later.

const obj = { name: 'Ben' };

function sayHello() {
  console.log(`Hello, ${this.name}!`);
}

const sayHelloToBen = sayHello.bind(obj);

sayHelloToBen(); // Hello, Ben!
sayHello.call(obj); // Hello, Ben!
sayHello.apply(obj); // Hello, Ben!

Usage in a method call

If a function is a method of an object, then this refers to the object.

const person = {
  name: 'Ben',
  logThis: function() {
    console.log(this);
  }
}

person.logThis(); // { name: 'Ben', logThis: fn() }

Usage in a Regular function call (Free function invocation)

If a function is invoked in the global context, then this refers to the global object(in non-strict mode) or undefined(in strict mode).

For browsers, the global object is window.

// Browser

function showThis() {
  console.log(this);
}

showThis(); // Window { open: fn, alert: fn, ... }

When a function is declared in the global context, it becomes a property of the window object. Calling window.showThis() would yield the same result. This is why it's an implicit method invocation. (Refer the rule above this one)

If multiple rules apply, then the rule with higher precedence will apply.

const obj1 = {
    value: 1,
    showThis: function() {
        console.log(this);
    },
};

const obj2 = { value: 2 };

obj1.showThis.call(obj2); // { value: 2 }

In the example above, two rules are being applied: Method invocation and Explicit binding. As explicit binding has higher precedence, it gets to set the value of this.

Arrow functions

Arrow functions don't follow the rules stated above as they don't have a this value of their own. They pick the this value from the parent scope.

const person = {
  name: 'Ben',
  showThis: () => {
    console.log(this);
  },
  showThisWrapped: function() {
    const arrowFn = () => console.log(this);
    arrowFn();
  }
}

person.showThis(); // Window { open: fn, alert: fn, ... }
person.showThisWrapped(); // { name: 'Ben', showThis: fn, showThisWrapped: fn }

This is why you should avoid using arrow functions for event listeners. Event listeners bind the HTML element to the this value but if the handler is an arrow function, it is not possible.

document.querySelector('#cta').addEventListener('click', function(){
 console.log(this); // HTMLButtonElement
})

document.querySelector('#cancel').addEventListener('click', () => {
 console.log(this); // Window
})

Summary

In a function constructor(new Person()), this will be the newly created object instance.
If explicitly bound using bind(), call() or apply(), this inside the function will be set to the value provided.
Inside a method, this is set to the object that method is a property of.
Inside a free function invocation, this points to global object(non-strict mode) or undefined(strict mode).
If multiple rules apply, the rule stated first(1-4) will apply.
Arrow functions don't have their own this. Its value is picked from the parent scope.

Like what you just read? Consider joining the waitlist on Frontend Camp ✌️

Event Loop Explained

Sanjeev Sharma — Sat, 07 Sep 2024 13:14:25 +0000

Another one among the popular frontend interview questions. It tests interviewees depth of knowledge in JavaScript ecosystem.

This is question #4 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider signing up on Frontend Camp.

Before we dig into the event loop, I want you to look at the following illustration. You might not understand all the components mentioned here, but it's better to build a mental model before we start.

We'll now zoom in on each of the components one by one and build our understanding of the Event Loop.

You might be surprised to know that APIs like fetch and setTimeout are not native to JavaScript. These APIs are provided by the JavaScript runtime environment.

Every JavaScript runtime comes with a JavaScript engine. In Chrome and Node.js, it's V8, and in Firefox, it's SpiderMonkey. The JavaScript engine mainly consists of two components: the Heap and the Call Stack.

During execution, the Heap is used for dynamic memory allocation, and the Call Stack is used to store the execution context. We'll mainly focus on the Call Stack in this article.

Call Stack

JavaScript, being a single-threaded language, comes with a single Call Stack. The Call Stack operates on the Last In, First Out (LIFO) principle. When a function execution starts, it is pushed onto the stack. After the execution is complete, it's popped off the stack, and the control returns to the calling function or the main program. This LIFO structure ensures that the most recently called function is always the first to complete.

Here's an illustration to visualize it.

When the script execution starts, the global execution context is created(let's call it main()) and pushed onto the Call Stack, followed by:

console.log("Hello") is pushed onto the call stack. Its output is logged in the console, and then it's finally popped off the stack.
After this, we have three function declarations - fn1(), fn2(), and fn3(). These don't get pushed to the Call Stack as we haven't executed them yet, but memory is allocated to store these functions. The exact location of this memory allocation can vary depending on the JavaScript engine's implementation.
When we reach fn3(), it's pushed onto the Call Stack. Inside fn3(), we make another call to fn2(). Following the LIFO principle, fn2() is pushed onto the Call Stack on top of fn3(), and its execution starts. Once fn2() finishes execution, it's popped off the stack, and the control returns back to fn3(). fn3() then proceeds with the rest of the execution and gets popped off the stack.
Finally, control reaches back to the main program, and it moves to the next line - execute fn1(). fn1() goes through the same process again. It's pushed onto the stack, and an execution context is created for it. Once it's done executing, it's popped off the stack, and the control reaches back to the main program.
In the end, when the script is done executing, main()(global execution context) is also popped off the stack, and the Call Stack is empty!

JavaScript, being a single-threaded language, can only do one thing at a time. When there's stuff to do on the Call Stack and JavaScript is busy executing it, it cannot do anything else. This is why it's important not to put long-running tasks on the Call Stack.

But then how does JavaScript support async tasks like API calls and setTimeout?

Let's understand this with another example.

This example uses setTimeout to execute a function later. If you notice, JavaScript didn't wait for 3 seconds before moving on to the next line. Then how does JavaScript know when the timer runs out? It can only do one thing at a time. If it's not counting up to 3 seconds, who is?

Turns out, JavaScript offloads these kinds of async tasks to the browser via Web APIs.

When the control reaches the setTimeout, it gets pushed onto the Call Stack. It tells the browser - Hey, can you remind me to run this fn after t milliseconds? and then continues with the rest of the program. Now, it's the browser's job to keep track of the timer.

But what happens when the timer runs out?

Web APIs cannot push anything directly onto the Call Stack. There could be multiple callbacks from setTimeouts or fetch calls waiting to be run. If everything gets pushed onto the Call Stack, things will go haywire. You'd see unexpected results, with the Call Stack being hijacked randomly.

This is where the Task Queue comes in. It is also known as the Macrotask Queue or Callback Queue.

Also, note that the browser can perform multiple tasks in parallel. The underlying libraries are built on multi-threaded languages.

Task Queue

When the timer runs out, the callback function from setTimeout is pushed into the Task Queue. The Task Queue (also known as the Callback Queue) holds callbacks from Web APIs and various event handlers waiting to be executed.

Some examples of tasks that go into Task queue:

setTimeout and setInterval callbacks
DOM events (like click, keypress, etc.)
AJAX/HTTP requests
I/O operations (in Node.js)

Once the Call Stack is empty, JavaScript picks up the tasks from the Task Queue and pushes them onto the Call Stack for execution.

So far, we've covered the Call Stack, Web APIs, and Task Queue. There's one final piece left to complete the puzzle, and it's an important one - the Microtask Queue.

Understanding the difference between these queues is crucial for grasping how JavaScript prioritizes and executes asynchronous operations.

Microtask Queue

Not everything gets pushed to the Task Queue. Modern APIs that support promises get pushed to the Microtask Queue. This queue has higher priority than the Task Queue.

Here's a list of items that use the Microtask Queue:

Promise handler callbacks (then(callback), catch(callback), and finally(callback))
Execution of async function bodies following await
queueMicrotask callbacks
MutationObserver callbacks

Once the Call Stack is empty, before checking the Task Queue, JavaScript checks the Microtask Queue. It executes all the callbacks(aka microtasks) available in the Microtask Queue and then moves to the Task Queue.

Here's an example to help you visualize it:

In the example above, there's an additional Promise-based fetch call. When the server responds, its callback will be pushed to the Microtask Queue.

When the Call Stack is empty, the Microtask Queue is checked. If we have the response callback ready, it's pushed onto the Call Stack. Once the Microtask Queue is empty, the Task Queue is checked. If we have the setTimeout's callback ready in the Task queue, it's pushed onto the Call Stack.

If we hadn't received the API response in time and the Microtask Queue was empty, then setTimeout's callback would have been executed first.

Key points about these two queues:

Tasks from both queues are only picked once the Call Stack is empty.
The Microtask Queue has high priority, so it's checked first. All the tasks available in the Microtask Queue are executed before the Task Queue is checked.
After each task execution from the Task Queue, the Microtask Queue is checked again. It could be the case that one of the tasks from the Task Queue led to the insertion of a callback in the Microtask Queue. Being high priority, it must be checked frequently.

Remember: Only one item is executed from the Task Queue before the Microtask Queue is checked again, whereas all the items from the Microtask Queue are executed before checking anything else. The Microtask Queue must be emptied when control comes to it!

The Event Loop: Tying It All Together

All the mechanisms we've discussed - the Call Stack, Web APIs, Task Queue, and Microtask Queue - are orchestrated by what's known as the Event Loop.

The Event Loop is the heart of JavaScript's concurrency model. It continuously checks the Call Stack and, when it's empty, looks at the Microtask Queue and Task Queue. It's responsible for moving callbacks from these queues to the Call Stack for execution, maintaining the order and priority we've discussed.

This process allows JavaScript, a single-threaded language, to handle asynchronous operations efficiently, enabling non-blocking I/O operations and creating the illusion of multi-threading.

Understanding the Event Loop is crucial for writing efficient and responsive JavaScript code, whether you're working on browser-based applications or server-side with Node.js.

Summary

JavaScript is single-threaded but can handle asynchronous operations. The Event Loop creates the illusion of multi-threading in JavaScript.
The JavaScript Engine consists of the Heap (for memory allocation) and the Call Stack.
The Call Stack follows LIFO (Last In, First Out) structure for function execution.
Web APIs (like setTimeout, fetch) are provided by the browser, not JavaScript itself.
Web APIs offload asynchronous tasks from the Call Stack to enable non-blocking execution.
The Task Queue (or Callback Queue) holds callbacks from Web APIs (e.g., setTimeout, DOM events).
The Microtask Queue has higher priority and contains Promise callbacks and queueMicrotask callbacks.
The Event Loop continuously monitors the Call Stack and both queues.
When the Call Stack is empty, the Event Loop first checks and empties the Microtask Queue.
After Microtasks, the Event Loop takes one task from the Task Queue and pushes it to the Call Stack. Then it repeats the process in point 9 until both Microtask Queue and Task queue are empty.
Microtasks always execute before the next Task(from Task/Callback queue), ensuring Promise resolutions are handled promptly.

Resources

What is JavaScript? One Definition to Cover It All.

Sanjeev Sharma — Thu, 15 Aug 2024 06:21:43 +0000

This might or might not get asked in an Interview but trust me once you read this you'll understand JS jargons much better. (Brownie points for using this during an Interview).

This is question #3 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider joining the waitlist on Frontend Camp.

JavaScript is a single-threaded, dynamically typed, interpreted programming language that supports multiple paradigms including object-oriented, functional, and imperative styles. It features prototype-based object orientation and an event-driven architecture.

This is the nerdy definition of JavaScript. But what does each term mean? Let's find out.

Single-threaded

JavaScript is a Single-threaded language meaning it only has one main thread of execution. It also means that it has a single call stack. When a function call is made, it's added to the top of the call stack. Once it's done executing, it's popped off the stack and the control moves to the next function in the call stack. Executing tasks sequentially is fundamental to JavaScript's nature but it does provide APIs to execute asynchronous operations(fetch and setTimeout are some examples).

Dynamically Typed

In JavaScript, variables are not explicitly declared with types. Types are associated with values and not variables as they are inferred at runtime. Types can also change during the lifecycle of a program. This feature makes JS flexible but it can be susceptible to type-related errors. Tools like TypeScript help in adding static types during development but it is eventually compiled to JS.

Interpreted Programming Language

Unlike compiled languages such as Java, JavaScript is not compiled into machine code before execution. Instead the code is read, interpreted, and executed line by line at runtime. However, to improve performance, modern JavaScript engines use Just-In-Time(JIT) compilation which compiles chunks of code on-the-fly. This approach improves execution speed.

Object-oriented

This programming paradigm organizes code into Objects, which are instances of classes or prototypes. The class keyword was introduced in ES6 for syntactic sugar. Under the hood, classes in JavaScript still use prototypes. This implementation of OOP is unique to JavaScript.

Functional

It is a programming paradigm which promotes writing declarative code by emphasizing the use of functions. Some of the key concepts are:

Pure functions: Functions that always produce the same output for given inputs and have no side effects.
Higher-order functions: Functions that can take other functions as arguments or return them as results.
Immutability: Treating data as immutable, though JavaScript doesn't enforce this by default.
First-class functions: Functions are treated as first-class citizens, meaning they can be assigned to variables, passed as arguments, or returned from other functions.
Function composition: Building complex functionality by combining simpler functions.

JavaScript supports these functional programming concepts alongside its other paradigms, allowing developers to use functional techniques where appropriate.

Imperative

Imperative programming is a paradigm where the code explicitly describes the sequence of steps that the program must take to reach the desired state. JavaScript fully supports all necessary constructs like variables, loops, conditionals, and operators which are required for writing imperative code. This approach allows for precise control over the program's execution flow. It is often used for implementing algorithms and managing complex state changes.

Prototype-based Orientation

JavaScript uses a prototype-based object model, which is a form of object-oriented programming where objects are the primary entities. Unlike class-based languages, JavaScript uses prototypes to implement inheritance and share properties and methods between objects.

Key aspects of prototype-based orientation in JavaScript include:

Object creation: Objects can be created directly without defining a class first.
Prototype chain: Each object has a link to another object called its prototype. If a property or method isn't found on an object, JavaScript looks for it in the prototype, then the prototype's prototype, and so on.
Inheritance: Objects can inherit properties and methods from other objects through their prototype chain.

This prototype-based system allows for powerful and flexible object-oriented programming.

Event-driven Architecture

JavaScript's event-based architecture is a programming approach where the flow of the program is determined by events such as user actions, sensor outputs, or messages from other programs. This is fundamental to how JavaScript interacts with web browsers and handles asynchronous operations.

Key aspects of JavaScript's event-based architecture include:

Event listeners: Functions that "listen" for specific events and execute when those events occur.
Event loop: A continuous process that checks for and dispatches events to their listeners.
Asynchronous programming: Allows code to run without blocking the main thread, crucial for responsive web applications.

This architecture enables JavaScript to handle user interactions, API calls, timers, and other asynchronous operations efficiently, making it well-suited for creating interactive web applications.

All these concepts combined make JavaScript a versatile language which can be used on a variety of platforms like Web, Mobile, Server, and AR.

Notes

For your interview, remember this definition:

JavaScript is a single-threaded, dynamically typed and interpreted-compiled language. It is a cross-platform language but mainly used on web for adding interactivity to pages.

Resources

Frontend Camp
What does it mean by Javascript is single threaded language
Interpreted vs Compiled Programming Languages

Debouncing and Throttling

Sanjeev Sharma — Fri, 09 Aug 2024 10:27:42 +0000

Another one among the popular frontend interview questions. It tests interviewees knowledge on JS, Performance and FE System Design.

This is question #2 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider signing up on FrontendCamp.

Debouncing and Throttling work on the same principle - delay stuff - but still have very different approach and use cases.

Both the concepts are useful for developing a performant application. Almost all the websites you visit on a daily basis use Debouncing and Throttling in some way or the other.

Debouncing

A well known use case of debouncing is a typeahead(or autocomplete).

Imagine you are building a search feature for an E-commerce website that has thousands of products. When a user tries to search for something, your app would make an API call to fetch all the products that match the user's query string.

const handleKeyDown = async (e) => {
 const { value } = e.target;
 const result = await search(value);
 // set the result to a state and then render on UI
}

<Input onKeyDown={handleKeyDown} />

This approach looks fine but it has some issues:

You're making an API call on each key press event. If a user types 15 characters, that's 15 API calls for a single user. This would never scale.
When the result from these 15 API calls arrives, you only need the last one. Result from previous 14 calls will be discarded. It eats up a lot of user's bandwidth and users on slow network will see a significant delay.
On the UI, these 15 API calls will trigger a re-render. It will make the component laggy.

The solution to these problems is Debouncing.

The basic idea is to wait until the user stops typing. We'll delay the API call.

const debounce = (fn, delay) => {
 let timerId;
 return function(...args) {
  const context = this;

  if (timerId) {
    clearTimeout(timerId);
  };
  timerId = setTimeout(() => fn.call(context, ...args), delay);
 }
}

const handleKeyDown = async (e) => {
 const { value } = e.target;
 const result = await search(value);
 // set the result to a state and then render on UI
}

<Input onKeyDown={debounce(handleKeyDown, 500)} />

We've extended our existing code to make use of debouncing.

The debounce function is generic utility function that takes two arguments:

fn: The function call that is supposed to be delayed.
delay: The delay in milliseconds.

Inside the function, we use setTimeout to delay the actual function(fn) call. If the fn is called again before timer runs out, the timer resets.

With our updated implementation, even if the user types 15 characters we would only make 1 API call(assuming each key press takes less than 500 milliseconds). This solves all the issues we had when we started building this feature.

In a production codebase, you won't have to code your own debounce utility function. Chances are your company already uses a JS utility library like lodash that has these methods.

Throttling

Well, Debouncing is great for performance but there a some scenarios where we don't want to wait for x seconds before being notified of a change.

Imaging you're building a collaborative workspace like Google Docs or Figma. One of the key features is a user should be aware of changes made my other users in real time.

So far we only know of two approaches:

The Noob approach: Any time a user moves their mouse pointer or types something, make an API call. You already know how bad it can get.
The Debouncing approach: It does solve the performance side of things but from a UX perspective it's terrible. Your coworker might write a 300 words paragraph and you only get notified once in the end. Is it still considered real-time?

This is where Throttling comes in. It's right in middle of the two approaches mentioned above. The basic idea is - notify on periodic intervals - not in the end and not on each key press, but periodically.

const throttle = (fn, time) => {
 let lastCalledAt = 0;

 return function(...args) {
  const context = this;
  const now = Date.now();
  const remainingTime = time - (now - lastCalledAt);

  if (remainingTime <= 0) {
   fn.call(context, ...args);
   lastCalledAt = now;
  }
 }
}

const handleKeyDown = async (e) => {
 const { value } = e.target;
 // save it DB and also notify other peers
 await save(value);
}

<Editor onKeyDown={throttle(handleKeyDown, 1000)} />

We've modified our existing code to utilise throttle function. It takes two arguments:

fn: The actual function to throttle.
time: The interval after which the function is allowed to execute.

The implementation is straight-forward. We store the time when the function was last called in lastCalledAt. Next time, when a function call is made, we check if time has passed and only then we execute fn.

We're almost there, but this implementation has a bug. What if last function call with some data is made within the time interval and no call is made after that. With our current implementation, we will lose some data.

To fix this, we'll store the arguments in another variable and initiate a timeout to be called later if no event is received.

const throttle = (fn, time) => {
 let lastCalledAt = 0;
 let lastArgs = null;
 let timeoutId = null;

 return function(...args) {
  const context = this;
  const now = Date.now();
  const remainingTime = time - (now - lastCalledAt);

  if (remainingTime <= 0) {
   // call immediately
   fn.call(context, ...args);
   lastCalledAt = now;
   if (timeoutId) {
     clearTimeout(timeoutId);
     timeoutId = null;
   }
  } else {
    // call later if no event is received
    lastArgs = args;
    if (!timeoutId) {
      timeoutId = setTimeout(() => {
        fn.call(context, ...lastArgs);
        lastCalledAt = Date.now();
        lastArgs = null;
        timeoutId = null;
      }, remainingTime);
    }
  }
 }
}

This updated implementation makes sure we don't miss out on any data.

Lodash also provides a throttle utility function.

Summary

Debouncing and Throttling are performance optimization techniques.
Both of these work on a similar principle - delay things.
Debounce waits for t after the last event is received whereas Throttling executes the fn periodically in t time.
Debouncing is used in search features and Throttling is used in Real-time apps(not limited to these).

Resources

FrontendCamp
lodash

Understanding async and defer

Sanjeev Sharma — Thu, 08 Aug 2024 13:16:12 +0000

This is one of the popular frontend interview questions. It tests interviewees knowledge on HTML, JS and Performance.

This is question #1 of Frontend Interview Questions series. If you're looking to level up your preparation or stay updated in general, consider signing up on FrontendCamp.

The script tag is used to add JavaScript to an HTML page. It could be an inline script or an external script.

<body>
  <!-- Some code before it -->

  <script>
    console.log("This is an inline script.");
  </script>

  <script src="https://example.com/external-script.js" />

  <!-- Some code after it -->
</body>

While parsing the HTML, if browser encounters a script tag it will stop HTML parsing and start executing the JS script. If it's inline it will start with execution straight away but if it's an external script, it will be downloaded and then executed.

During this time, when JS script is being downloaded and executed, HTML parsing is blocked. It can only resume once the browser is done with executing the JS script.

Do you see what's wrong here? This will cause performance issues for the end user. If we have a lot of scripts or any script takes a lot of time to execute, user won't see the content of the page for a long time.

To solve exactly this, we have two attributes: async and defer.

`async`

If the async attribute is present, the script will be downloaded in parallel to parsing HTML and executed as soon as it is available.

If multiple scripts use the async attribute, the order of execution might be different than the order in which they appear in the HTML. The script that is available first will be executed first.

<body>
  <!-- Some code before it -->

  <script async src="https://example.com/external-script.js" />

  <!-- Some code after it -->
</body>

`defer`

If the defer attribute is present, the script will be downloaded in parallel to HTML parsing(just like async) but executed after HTML parsing is finished and before firing DOMContentLoaded.

If multiple scripts use the defer attribute, the order of execution will be maintained, unlike async.

<body>
  <!-- Some code before it -->

  <script defer src="https://example.com/external-script.js" />

  <!-- Some code after it -->
</body>

Summary

Both async and defer download script without blocking HTML parsing.
async script will be executed as soon as it's available. It could potentially block HTML parsing.
defer script will only be executed once HTML parsing is complete but before firing DOMContentLoaded.
Use async, if the order of execution doesn't matter and the script doesn't modify the DOM.
Use defer, if the order is execution is important or the script modifies the DOM.
Also, note that these attributes don't work on inline scripts i.e. scripts without src attribute.
If both async and defer are added, async takes precedence.

Resources

MDN: The script element
FrontendCamp

Introducing DEV AI: Your Tech Blogging Sidekick

Sanjeev Sharma — Sat, 13 Apr 2024 17:01:31 +0000

This is a submission for the Cloudflare AI Challenge.

What I Built

Presenting DEV AI ✨, an AI assistant for the DEV platform. The app caters to two categories of users: Readers and Creators.

For readers 👀:

It can summarize an article for you.
It can translate the summarization into your preferred language.
It can do a sentiment analysis on the article.

For creators ✍️:

It can generate a cover image for you.
It can create a structured plan for your next article.

Demo

🔗 DEV AI

Reader mode

Creator mode

My Code

thesanjeevsharma / dev-to-ai

Unofficial DevTo AI Assistant

DEV AI

Unofficial AI app for DEV readers and creators, created as part of Cloudflare AI x DEV challenge.

Demo

🔗 https://dev-to-ai.pages.dev

Features

The app runs in two modes: Creator and Reader mode.

Creator mode: Let's you generate a cover image and action plan for your next article.
Reader mode: Let's you summarize and translate an article. It also provides a sentiment analysis of the article.

Installation Steps

Make sure you have the required env variables set from .env.example file.

NEXT_APP_DEV_TO_API=https://dev.to/api/articles
CF_WORKER_AI=https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai/run/@cf
CF_TOKEN=<TOKEN>

Replace ACCOUNT_ID and TOKEN with the value you get from Cloudflare. Please generate the token with Workers AI read and edit access.

Run npm i
Run npm run dev to run the project locally

View on GitHub

Journey

Initially, I was planning to build a summarizer for YouTube videos but YT already does that. Also, the same idea has been implemented by quite a few devs. It wasn't unique and it would have been a throwaway project for me.

Then while browsing DEV, I got this idea of summarizing articles instead. I know it's been built too, but not specifically for DEV. I added translation and sentiment analysis as well to take it a step further.

Later on, I extended the app to have a Creator mode. I've used ChatGPT countless times whenever I've hit the writers block, which is why I wanted to build something to help writers like me. I also spend a lot of time trying to find the right cover image for my article, hence decided to add an Image generation feature as well.

This is my first project with an AI integration. Now, I've got some idea about how these models work from an API perspective and I can explore further in this area. It was a fun challenge and filled with lots of learning.

Future plans: I plan to keep the app running and make gradual updates to it(Hopefully, these AI models will keep getting better). It's actually a resume-worthy project. ✨

Techstack: NextJS, TailwindCSS and Cloudflare Pages.

Models used:

@cf/facebook/bart-large-cnn for summarizing. It's in beta right now, therefore results aren't that great. I tried switching to other text generation models but the input text is limited on those. I guess I'll have to stick with this one for now.
@cf/meta/m2m100-1.2b for translation.
@cf/huggingface/distilbert-sst-2-int8 for sentiment analysis.
@cf/stabilityai/stable-diffusion-xl-base-1.0 for generating the cover image based on description provided by the user.
@cf/meta/llama-2-7b-chat-fp16 for creating a writing plan for article based on the description provided.

Multiple Models and/or Triple Task Types

Yes, I've used 5 models as stated above.

Introduction to NGINX

Sanjeev Sharma — Tue, 19 Dec 2023 04:46:44 +0000

NGINX, pronounced as 'engine-x', is an open-source web server that is mainly used for Reverse proxy, Caching, and Load balancing.

If you're into web dev, at some point in your career you might have to work with NGINX. This article will help you get started with NGINX. By the end, you'll be able to setup your own NGINX web server. You'll also understand terms like load balancing and reverse proxy.

Why NGINX?

NGINX is widely used for serving web content. It is known for its high performance, stability, and efficiency, making it a popular choice for various web applications and websites.

Some key features of NGINX are:

Web Server 🤖: It can serve static content(such as HTML, CSS and images) directly to clients, making it efficient for delivering web pages.
Reverse Proxy ⏩: It can act a reverse proxy by forwarding client's requests to other servers. It is a commonly used practice for security and scalability.
Load Balancer ⚖️: It can route incoming traffic to different server instances ensuring optimal resource utilization.
SSL/TLS Termination 🔐: It can handle SSL/TLS termination, encrypting and decrypting data between clients and servers.
Performance Optimization ⚡️: It is designed to be lightweight and efficient, capable of handling a large number of concurrent connections with low resource usage.

Installation

Ubuntu/Debian

sudo apt update
sudo apt install nginx

After installation, NGINX will automatically start in the background. To check the status, run:

sudo systemctl status nginx

MacOS

We can install it using brew

brew install nginx

After installation, you can run it using:

brew services start nginx

Windows

Download the latest stable version of NGINX from the official website: NGINX Download.
Extract the downloaded zip file to a location of your choice.
Navigate to the NGINX directory and run nginx.exe. NGINX should start.

Configuration

To find the configuration file, run:

nginx -t

nginx: the configuration file /opt/homebrew/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /opt/homebrew/etc/nginx/nginx.conf test is successful

This command tests the configuration file for syntax errors and typos, without applying it. It will also reveal the path to the main configuration file.

You can either edit this file directly or create a new one to follow along.

Serving HTML

If you check the nginx.conf file, you'll see a lot of blocks wrapped in {} and a lot of key-value pairs inside these blocks.

These blocks are known as contexts and the key-value pairs are known as directives for that context.

We'll clear the file and start from scratch. Your nginx.conf should look like this:

events {}

http {
    server {
        listen 8080;
        root /Users/syfe/Desktop/tutorials/nginx-test/html;
    }
}

You only need events and http contexts to successfully load a configuration. Inside http, we have the server context that has the configuration for our web server.

It tells the server to listen on port 8080 and set root for serving files as /Users/syfe/Desktop/tutorials/nginx-test/html.

Inside the html directory, we'll create an index.html file.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>

<body>
    <h1>Hello, world!</h1>
</body>

</html>

This is how directory structure looks currently.

If you created a new conf file, you can load it by running:

nginx -c path_to_your_file

And after making changes to any conf file, you can apply it using:

nginx -s reload

If you go on http://localhost:8080, you'll see the html being served. 🎉

Serving other static content

If you try to add styles to your HTML content using a CSS file and serve it using the current configuration it will not work.

To make this work, you have to set the correct mime types in the configuration.

...
http {
  types {
    text/css   css;
    text/html  html;
  }

  server {
    ...
  }
}
...

But manually adding these mime types for all different kinds of assets is cumbersome. Therefore, NGINX comes with a default mime.types file that can be used here.

After adding the default mime types file, our configuration looks like this:

events {}

http {
    # include mime.types; (if you did not create a custom file)
    include /opt/homebrew/etc/nginx/mime.types;

    server {
        listen  8080;
        root    /Users/syfe/Desktop/tutorials/nginx-test/html;
    }
}

After reloading the conf, our HTML and CSS should be working as expected but now we have support for a lot of types.

The `location` block

Let's assume you've the following directory structure:

Going to /animals, will serve the index.html file inside the animals directory. What if you want to have another endpoint /forest that serves the same file?

We can use the location block to specify the full path and then using alias we can set the directory that will serve the files.

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    server {
        listen  8080;
        root    /Users/syfe/Desktop/tutorials/nginx-test/html;

        location /forest {
            alias /Users/syfe/Desktop/tutorials/nginx-test/html/animals;
        }
    }
}

With the above configuration, requests to /forest will be served from animals directory.

What if someone deletes the animals directory or the file we're trying to serve is not available? We can provide fallback files using try_files directive.

Let's create a fallback file.

Now, let's update the configuration.

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    server {
        listen  8080;
        root    /Users/syfe/Desktop/tutorials/nginx-test/html;

        location /animals {
            root /Users/syfe/Desktop/tutorials/nginx-test/html;
            try_files /animals/fallback.html /index.html =404;
        }
    }
}

Now, when a user visits /animals:

First the server will look for /animals/index.html.
If it doesn't exist, it'll look for /animals/fallback.html.
If our fallback file is missing it'll try to serve the index.html at root.
If it cannot find any file listed by us, it'll throw a 404 error.

Redirects

It is quite easy to set up redirections using NGINX. Let's update the configuration to redirect all incoming traffic from /birds to /animals.

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    server {
        listen  8080;
        root    /Users/syfe/Desktop/tutorials/nginx-test/html;

        location /animals {
            root /Users/syfe/Desktop/tutorials/nginx-test/html;
        }

        location /birds {
            return 307 /animals;
        }
    }
}

Returning with 307 does the trick.

Reverse Proxy

To forward requests to another server we can use the proxy_pass directive.

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    server {
        listen 8080;

        location / {
            proxy_pass http://192.168.10.5:8080;
        }
    }
}

Now, all the requests to localhost:8080 will be forwarded to http://192.168.10.5:8080. This is helpful when you don't want to reveal the actual server or want to relay requests to different servers based on different paths.

Load Balancing

Sometimes, in high traffic situations, we might spin up multiple instances to handle the load. NGINX can act as a load balancer and evenly distribute requests among all the instances.

This ensures a seamless experience for our users without any downtime.

Let's update the configuration to achieve this:

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    upstream instances {
        server 192.168.10.2:8080;
        server 192.168.10.3:8080;
        server 192.168.10.4:8080;
    }

    server {
        listen 8080;

        location / {
            proxy_pass http://instances;
        }
    }
}

The upstream block is used to specify a group of servers that can be referenced by proxy_pass. NGINX will automatically take care of distributing the requests evenly.

Logging

With all that you've learnt so far, you'll be able to do a lot of cool things. One final(and important) thing that will help you in your journey is - Logging.

Let's update the configuration to add access logs on our server:

events {}

http {
    include /opt/homebrew/etc/nginx/mime.types;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" ';
    access_log /Users/syfe/Desktop/tutorials/nginx-test/access.log main;

    server {
        listen 8080;
        root /Users/syfe/Desktop/tutorials/nginx-test/html;
    }
}

We provide the format using log_format directive. The access_log directive takes the path to store the logs and the format we specified earlier.

That's it for this post! I hope this will get you started or at least now you understand what NGINX is. The official documentation for NGINX is well written if you wish to explore further.

🤝 I'd love to connect on LinkedIn or X.

Syfe is hiring devs. 👨‍💻🌏

Forem: Sanjeev Sharma

CORS, Preflight Requests, and Common Cross-Origin Issues

What is CORS?

Preflight Requests

Common CORS Issues

Summary

Preparing for Frontend interviews?

Event Delegation Pattern

Benefits of Event Delegation

Common Pitfalls

Summary

Preparing for Frontend interviews?

10 Backend Terms Every Frontend Developer Should Know

1. Rate Limiting

2. Load Balancing

3. Caching

4. CDN

5. Microservices

6. API Gateway

7. Webhook

8. Sharding

9. Proxy

10. Message Queues

Preparing for Frontend interviews?

Event Flow: Bubbling & Capturing

Event Bubbling

Event Capturing

Summary

Cookies, Local storage and Session storage

Cookies

Local storage

Session storage

Summary

`this` in JavaScript Explained

Usage in a Function constructor

Explicitly binding this

Usage in a method call

Usage in a Regular function call (Free function invocation)

Arrow functions

Summary

Event Loop Explained

Call Stack

Task Queue

Microtask Queue

The Event Loop: Tying It All Together

Summary

Resources

What is JavaScript? One Definition to Cover It All.

Single-threaded

Dynamically Typed

Interpreted Programming Language

Object-oriented

Functional

Imperative

Prototype-based Orientation

Event-driven Architecture

Notes

Resources

Debouncing and Throttling

Debouncing

Throttling

Summary

Resources

Understanding async and defer

async

defer

Summary

Resources

Introducing DEV AI: Your Tech Blogging Sidekick

What I Built

Demo

My Code

thesanjeevsharma / dev-to-ai

Unofficial DevTo AI Assistant

DEV AI

Demo

Features

Installation Steps

Journey

Introduction to NGINX

Explicitly binding `this`

`async`

`defer`

The `location` block