DEV Community: Prathamesh Lakare

SQL vs NoSQL

Prathamesh Lakare — Thu, 22 May 2025 13:34:49 +0000

Yesterday I had a session with Ankita Tripathi. It was a really great session, and I learned a lot about SQL databases and NoSQL databases.

What I Understand from SQL vs NoSQL

SQL (Structured Query Language)

SQL is a database that stores data in a vertical way. In SQL databases, you store data in the form of rows and columns. The first row contains fields, and the next rows contain data for those fields. So, it's like adding data vertically.

SQL is mostly used in applications where you already know the structure of the data (i.e., fields) before storing it. For example, if you want to store user data or banking data, you can use a SQL database.

NoSQL (Not Only SQL)

NoSQL is a database that stores data in a horizontal way. In this, data is stored in JSON format, and you can have as many fields as you want. It is generally faster compared to SQL.

When you have dynamic data with multiple fields, you use a NoSQL database. For example, when storing product data, you use NoSQL. It stores data in the form of JSON and keeps adding new fields as needed, which makes it scalable.

Examples

Flipkart

Most of the data in Flipkart is stored using NoSQL. That's because it has many products with different categories and different data structures. If SQL were used here, it would get very complicated. For example, in the mobile category, you might see fields like screen size and accessories, whereas in the clothing category, you see size and color. NoSQL handles this easily.

Netflix

Netflix uses a hybrid model, which means it uses both SQL and NoSQL. When it comes to data like recommendations or watch-later lists, NoSQL is used because it's faster when dynamic tasks are happening. But for things like user data or payment data, SQL is used since it provides better insights and structure.

Uber (Ride Sharing)

Uber also uses a NoSQL database because there are frequent changes in fields with different categories. For example, if Uber introduces a new feature like pool sharing or bus rides, with SQL they would have to create new fields manually, which can make the app unscalable. But with NoSQL, it's easier to add new features with different fields. Also, for real-time ride locations, faster data access is needed, which NoSQL provides.

Why We Use SQL

SQL stores data in rows and columns, which makes it easier to generate insights like charts and reports. It is great for structured data like banking systems where all fields are required. If one field is null, it throws an error — which is actually useful when you want to make sure all information is filled in.

Why We Use NoSQL

NoSQL stores data in JSON format, and you can add fields anytime. It's flexible and works well when you're adding new features or when speed is important. Operations in NoSQL are generally faster, and it allows you to update or insert new fields easily without changing the overall structure.

CAP Theorem

CAP Theorem is a fundamental concept used in distributed systems. It gives three guarantees:

Consistency: Returns the most recent data or an error.
Availability: Every request receives a response.
Partition Tolerance: The system keeps working even if there are network issues.

According to the Theorem

A distributed system must tolerate partitions. It can only choose one of the other two — consistency or availability.

CP: System prefers consistency over availability (like NoSQL databases).
AP: System prefers availability over consistency (like SQL databases).

Understanding the Virtual DOM in React

Prathamesh Lakare — Mon, 12 May 2025 06:32:23 +0000

React is fast — but how is it so fast? One of the biggest reasons is the Virtual DOM.

What is the DOM?

The DOM (Document Object Model) is a tree-like structure representing the HTML elements on a web page. Whenever you change something (like text or style), the DOM has to update, which can be slow if not handled properly.

What is the Virtual DOM?

The Virtual DOM is a lightweight copy of the real DOM that React keeps in memory.

Instead of directly updating the real DOM every time something changes, React updates the Virtual DOM first, then compares it with the previous Virtual DOM (this process is called diffing). React then finds out what actually changed and updates only those parts of the real DOM.

This makes the whole process faster and more efficient.

How React Uses Virtual DOM

Here's a simple breakdown:

You change the state or props in your component.
React creates a new Virtual DOM tree.
It compares the new Virtual DOM with the old one.
React finds the differences (called “diffing”).
React updates only the changed nodes in the real DOM.

This is much faster than re-rendering the entire DOM.

Why is Virtual DOM Better?

Performance

React avoids unnecessary real DOM updates, which are expensive and slow.

Efficient Re-rendering

Only the parts of the UI that actually change get updated.

Smooth UI

Your app feels fast and responsive, even with many components.

Understanding the JavaScript Event Loop

Prathamesh Lakare — Mon, 12 May 2025 05:25:03 +0000

If you've ever wondered how JavaScript handles asynchronous tasks like setTimeout, fetch, or Promises while being a single-threaded language—you're not alone.

How JavaScript Executes Code

JavaScript runs in the browser using a JavaScript engine. When your code executes, it goes into the call stack, which handles synchronous tasks—code that runs line by line.

But when there's asynchronous code, things work a bit differently.

Web APIs

The browser provides Web APIs to handle asynchronous operations.

When such code runs, it's sent off to the Web API environment provided by the browser—not the call stack. Once the asynchronous operation is complete, its callback is moved to the callback queue (or task queue).

Microtasks vs Macrotasks

Not all tasks in the callback queue are treated equally.

Microtasks: Promises, queueMicrotask, MutationObserver
Macrotasks: setTimeout, setInterval, setImmediate, UI rendering

Microtasks have higher priority and are always executed before macrotasks in each cycle of the event loop.

Event Loop

The event loop is the behind-the-scenes mechanism that keeps everything running smoothly.

It constantly checks: Is the call stack empty?

If yes, it picks the first task from the callback queue (starting with microtasks) and moves it into the call stack for execution.

This is how JavaScript handles asynchronous code without blocking the main thread.

A Journey Through Time: The History of Web Applications

Prathamesh Lakare — Fri, 10 Jan 2025 06:42:50 +0000

Modern web applications are often built as Single Page Applications (SPAs). But if we look back at the history of web development, things were quite different.

In the past, web applications rendered all their content on the server-side. This meant the server sent fully prepared HTML, CSS, and JavaScript files to the browser for each request. The browser would then display the content by rendering these files.

A great example of this approach, which still exists today, is Wikipedia. When you visit Wikipedia, all the content for the requested page is loaded upfront. If you disconnect your internet after the page loads, you'll still be able to view the content because everything, including the HTML, CSS, and JavaScript, has already been delivered to your browser.

However, server-rendered applications like this come with some downsides:

Memory Usage: These apps often consume more memory, which can lead to slower device performance, especially on resource-constrained devices.
Performance Bottlenecks: Every time you navigate to a new page, the browser makes a new request, and the server sends the entire page again, resulting in slower load times compared to modern SPAs.

In contrast, modern SPAs work differently:

When you visit an SPA, the server sends a minimal HTML file along with bundled JavaScript and CSS files.
The browser uses these files to dynamically render content on the page, often fetching additional data via APIs without refreshing the whole page.
This reduces the load on devices and servers, making the experience smoother and faster.

To understand how traditional server-rendered apps work, think of the process like this:

The server receives the URL of the page you want to visit.
It processes the request and sends the full set of files (HTML, CSS, JS) to the browser.
The browser interprets these files to generate the content you see on the screen.
In these apps, the server doesn’t directly send the content you see. It sends the files required to create that content. The browser is responsible for converting those files into the visual layout and interactions on the webpage.