DEV Community: Debug Diaries

How ChatGPT Works (Simple Explanation for Beginners)

Debug Diaries — Mon, 20 Apr 2026 09:39:29 +0000

If you’ve ever wondered what happens when you type a prompt into ChatGPT, this article breaks it down in the simplest way possible.

Let’s go step by step

High-Level Flow

User Input → Input Processing → Context Building → LLM → Output Processing → Response

1. Input Processing

When you enter a prompt:

Your input is cleaned and structured
Previous chat history is added
Text is converted into tokens (numbers the model understands)

Tokens are not always full words—they can be parts of words, spaces, or punctuation.

2. Context Building (Prompt Augmentation)

Before sending your input to the model, the system adds extra information:

Hidden system prompts (rules like “be helpful and safe”)
App-level instructions (tone, format)
Sometimes external data

This helps guide how the AI should respond.

3. LLM Processing (The Brain)

The request is sent to a Large Language Model (LLM).

The model:

Reads the full context (input + history + system instructions)
Generates a response token by token
Uses probability to predict the next word

Important: It doesn’t “think” like a human—it predicts patterns.

4. Output Processing

Before showing the result:

Safety filters are applied
Formatting is adjusted (like Markdown)
The response is finalized

Final Flow (Simplified Diagram)

[You]
   ↓
[Input Processing]
   ↓
[Context + Hidden Instructions]
   ↓
[LLM (Prediction Engine)]
   ↓
[Output Filtering & Formatting]
   ↓
[Final Response]

Important Note

Real-world systems like ChatGPT can also include:

Tool usage (APIs, calculators)
Retrieval systems (fetching external knowledge)
Memory layers

This is a simplified mental model to get started.

Why This Matters

Understanding this helps you:

Write better prompts
Debug AI responses
Build your own AI applications

What’s Next?

In the next post, I’ll explain how these models are actually created—from tokens to training to alignment.

How a Browser Renders a Webpage — And Where React, CSR, and SSR Fit In

Debug Diaries — Sun, 15 Mar 2026 14:02:36 +0000

When we type a URL in the browser and press Enter, a lot happens behind the scenes before the webpage appears on the screen. Understanding this process is important for frontend developers because it explains why some websites load instantly while others show a blank screen first.

In this article, we’ll walk through:

How a browser processes a request
How the UI is rendered
Where React, Client-Side Rendering (CSR), and Server-Side Rendering (SSR) come into play

1. The Request Process

When a user enters a URL like:

https://example.com

the browser performs several steps.

Step 1: Check Cache

The browser first checks whether the website resources are already stored locally in cache.

Step 2: DNS Lookup

If not found, the browser asks the Domain Name System to convert the domain name into an IP address.

Example:

example.com → 93.184.216.34

Step 3: Establish Connection

The browser opens a connection with the server using Transmission Control Protocol.

If the website uses HTTPS, a secure connection is established using Transport Layer Security.

Step 4: Send HTTP Request

The browser sends a request like:

GET /index.html HTTP/1.1
Host: example.com

2. Server Response

The server sends back resources such as:

HTML
CSS
JavaScript
Images
Fonts

These resources are often sent in chunks (streams), meaning the browser starts processing them before the entire file finishes downloading.

3. HTML Parsing and DOM Creation

Once the browser receives HTML, it begins parsing it immediately.

The browser converts HTML elements into a tree structure called the Document Object Model.

Example HTML:

<body>
  <h1>Products</h1>
  <p>Item 1</p>
</body>

DOM structure:

body
 ├── h1
 └── p

This structure allows JavaScript to access and modify elements dynamically.

4. CSS Parsing and CSSOM

When the browser encounters CSS files or <style> tags, it creates another structure called the CSS Object Model.

This maps selectors to their styles.

Example:

p {
  color: blue;
}

The browser builds a tree of style rules and applies them to the DOM elements.

5. Render Tree Creation

The browser combines:

DOM
CSSOM

to create a Render Tree.

This tree contains only visible elements.

Elements excluded include:

<meta>
<head>
elements with display: none

6. Layout (Reflow)

Next, the browser calculates the position and size of each element.

It determines:

width and height
position on the X and Y axis
how elements flow on the page

This step ensures the UI fits the device viewport correctly.

7. Paint

Once layout is calculated, the browser fills visual details such as:

colors
borders
text
shadows
images

At this stage the page becomes visually complete.

8. Compositing

Some elements are rendered on separate layers, such as:

sticky headers
popups
animations
transformed elements

These layers are sent to the GPU to render efficiently.

This final step is called compositing.

9. Where JavaScript Fits In

When the browser encounters a script:

<script src="app.js"></script>

HTML parsing pauses, and the browser:

downloads the JavaScript
executes it
resumes HTML parsing

This is why JavaScript can block page rendering.

To avoid blocking, developers use:

<script defer src="app.js"></script>
<script async src="analytics.js"></script>

async executes immediately after download
defer executes after HTML parsing finishes

10. Client-Side Rendering (CSR)

Many modern web apps built with React use Client-Side Rendering.

In CSR, the server sends minimal HTML:

<body>
  <div id="root"></div>
  <script src="main.js"></script>
</body>

The browser initially sees:

empty page

Then JavaScript runs and React builds the UI.

Example React code:

ReactDOM.createRoot(root).render(<App />)

React generates the DOM elements dynamically.

User Experience

page loads
↓
blank screen
↓
JavaScript loads
↓
UI appears

11. Server-Side Rendering (SSR)

Frameworks like Next.js use Server-Side Rendering.

Instead of sending empty HTML, the server renders the React components and sends fully built HTML.

Example response:

<div id="root">
  <h1>Products</h1>
  <p>Item 1</p>
</div>

Now the browser displays content immediately.

12. Hydration

After SSR HTML loads, JavaScript still downloads.

React then attaches event handlers to the existing HTML.

This process is called Hydration.

Before hydration:

button visible but not clickable

After hydration:

button becomes interactive

CSR vs SSR Comparison

Feature	CSR	SSR
Initial HTML	Empty	Fully rendered
First load	Blank screen	Content appears instantly
SEO	Limited	Better
Rendering location	Browser	Server

Understanding how the browser renders a webpage helps frontend developers:

optimize performance
avoid render-blocking issues
improve user experience
choose the right rendering strategy

CSR is great for highly interactive applications, while SSR improves initial load performance and SEO.

Modern frameworks like Next.js combine both approaches to deliver the best user experience.

JavaScript Explained: Set, WeakSet, Map & WeakMap – What They Are and When to Use Them

Debug Diaries — Tue, 17 Jun 2025 14:01:20 +0000

JavaScript isn’t just about arrays and objects anymore. As applications grow complex, we need smarter ways to store and manage data. That's where Set, WeakSet, Map, and WeakMap come in.

These built-in data structures provide more powerful and flexible options for working with collections. Let’s dive deep into each one, understand how they work, and when to use them in real-world scenarios.

Set – A Collection of Unique Values

What is it?
A Set is a special type of collection in JavaScript that lets you store unique values — no duplicates allowed.
You can think of a Set like a checklist where each item can appear only once.

Key Features:

Stores unique values only.
Values can be of any data type – numbers, strings, objects, etc.
Maintains the insertion order.
Provides utility methods like .add(), .has(), .delete(), and .clear().

const fruits = new Set();
fruits.add('apple');
fruits.add('banana');
fruits.add('apple'); // Duplicate, won’t be added again

console.log(fruits); // Set(2) { 'apple', 'banana' }
console.log(fruits.has('banana')); // true

When to Use:

You need a list of unique items (e.g., tags, filters).
You want to easily check for the presence of a value.
You want to remove duplicates from an array:

Example:

const arr = [1, 2, 2, 3];
const uniqueArr = [...new Set(arr)];
console.log(uniqueArr); // [1, 2, 3]

WeakSet – Sets with Weak References

What is it?

A WeakSet is similar to a Set, but it only stores objects and holds them "weakly," meaning:

The object references don’t prevent garbage collection.
If no other references to the object exist, it will be automatically removed from the WeakSet.

Key Features:

Only objects (not primitives) can be stored.
Items are held weakly and may be garbage collected.
Not iterable – you can't loop through a WeakSet.
Useful for memory-efficient temporary storage.

Example:

const person = { name: 'Alice' };
const visitedUsers = new WeakSet();

visitedUsers.add(person);
console.log(visitedUsers.has(person)); // true

// Later...
// person = null; // If this happens, the object may be removed from WeakSet

When to Use:

Tracking objects without creating memory leaks, like keeping track of DOM elements or users currently logged in.
You don’t need to iterate the collection.
You want automatic cleanup when the object is no longer used elsewhere.

Map – Key-Value Pairs with Powerful Features

What is it?
A Map is a collection of key-value pairs where keys can be any data type – unlike regular objects which only allow strings or symbols.

It’s like an enhanced Object but with predictable ordering and better performance for frequent additions/removals.

Key Features:

Any value (object or primitive) can be used as a key.
Maintains insertion order of key-value pairs.
Provides easy methods: .set(), .get(), .has(), .delete(), .clear(), and .size.

Example:

const userMap = new Map();
const user1 = { id: 1 };
userMap.set('name', 'John');
userMap.set(user1, 'Premium Member');

console.log(userMap.get('name')); // John
console.log(userMap.get(user1));  // Premium Member

When to Use:

You need keys that are not just strings.
You require frequent key-value pair manipulation.
You need guaranteed order of entries.
Ideal for building dictionaries, caching data, or implementing LRU caches.

WeakMap – Object Keys with Weak References

What is it?
A WeakMap is just like a Map, but with some constraints:

Only objects can be used as keys.
Those keys are held weakly, allowing them to be garbage collected.
It is not iterable and has limited methods.

Key Features:

Only object keys (no strings, numbers).
Automatically cleans up when the key object is no longer referenced.
Supports only .set(), .get(), .has(), and .delete().

Example:

const secretData = new WeakMap();
let user = { name: 'Tom' };

secretData.set(user, { accessLevel: 'admin' });
console.log(secretData.get(user)); // { accessLevel: 'admin' }

user = null; // Now, the user object and its secret data can be garbage collected

When to Use:

Storing private data related to DOM elements or users.
You want memory-efficient key-value storage.
You don’t need to enumerate keys.

Final Thoughts

While JavaScript's built-in objects like arrays and plain objects are great, Set, WeakSet, Map, and WeakMap give you more power and flexibility when managing data — especially as your applications grow in complexity.

Remember:

Use Set and Map when you need iterable collections with full control.
Use WeakSet and WeakMap for memory-sensitive or private data management.

Mastering these will help you write cleaner, more efficient, and scalable JavaScript code.

Understanding SOLID Principles in Frontend Development (with React Examples)

Debug Diaries — Wed, 21 May 2025 09:58:36 +0000

As frontend applications grow more complex, maintaining clean, scalable code becomes challenging. That’s where SOLID principles come in — a set of five design principles aimed at building better software. Though originally coined for object-oriented programming, they apply well to frontend development, especially when working with React.js.

In this blog, let’s break down each principle in simple terms with relatable React examples.

What is SOLID?

SOLID is an acronym:

S – Single Responsibility Principle
O – Open/Closed Principle
L – Liskov Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

Let’s explore each one.

1. Single Responsibility Principle (SRP)

A component should do one thing only.

// UI Component
function UserCard({ user }) {
  return <div>{user.name}</div>;
}

// Data Fetching Hook
function useUserData(userId) {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch(`/api/users/${userId}`).then(res => res.json()).then(setUser);
  }, [userId]);
  return user;
}

Each function does one job — one for UI, one for data. This separation makes the code easier to test, debug, and reuse.

2. Open/Closed Principle (OCP)

Components should be open for extension, but closed for modification.

function Button({ variant = 'primary', children }) {
  return <button className={`btn ${variant}`}>{children}</button>;
}

You can add new button styles (secondary, danger, etc.) without modifying the Button component. This prevents bugs and keeps components flexible.

3. Liskov Substitution Principle (LSP)

A child component should work in place of its parent without breaking the app.

function Button({ onClick, children }) {
  return <button onClick={onClick}>{children}</button>;
}

function DangerButton(props) {
  return <Button {...props} className="danger" />;
}

DangerButton behaves just like Button. If you replace Button with DangerButton, your app will still work — fulfilling the same expectations.

4. Interface Segregation Principle (ISP)

Components should only receive the props they actually use.

function UserSummary({ name, email }) {
  return (
    <div>
      <p>{name}</p>
      <p>{email}</p>
    </div>
  );
}

Passing only required props keeps components simple and reduces the chance of misuse or confusion when reusing them.

5. Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations.

function Login({ authService }) {
  const handleLogin = () => authService.login();
  return <button onClick={handleLogin}>Login</button>;
}

Instead of using a specific API method directly, Login depends on an authService. This allows easy mocking for tests and swapping out logic (e.g., for Google login or a mock server).

Conclusion

By applying SOLID principles, you:

Reduce bugs
Improve code reusability
Make your frontend easier to test and extend

Even if you're building a small app, following these principles leads to cleaner, more professional code. Start with Single Responsibility, and gradually adopt the rest as your projects grow.

Creating Custom Constraints: Writing Your Own @NotNull Annotation

Debug Diaries — Mon, 28 Apr 2025 05:43:09 +0000

When building Java applications, especially with frameworks like Spring or Jakarta EE, validation plays a critical role. You might be familiar with annotations like @NotNull, @Size, or @Email. But what if you need something more custom? Maybe you want a special kind of "NotNull" check — one that's tailored for your domain or offers better error messages.

In this post, we’ll walk through creating a custom constraint annotation, similar to @NotNull.

Why Create a Custom Constraint?

Specific validation logic: Maybe you want to check not only for null but also for empty strings, or to validate conditionally.
Custom error messages: Tailor the messages for your application’s tone.
Reusable across the codebase: Keep code clean and consistent.
Domain-specific validations: "Name must not be blank", "User ID must not be empty", etc.

Step 1: Create the Custom Annotation

Let’s create a simple @ConditionalNotNull annotation.

import jakarta.validation.Constraint;
import jakarta.validation.Payload;
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;

import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

@Documented
@Constraint(validatedBy = ConditionalNotNullValidator.class)
@Target({ METHOD, FIELD, ANNOTATION_TYPE, PARAMETER })
@Retention(RUNTIME)
public @interface ConditionalNotNull {

    String message() default "This field cannot be null";

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};
}

Explanation:

@Constraint points to the Validator class that will contain the actual validation logic.
@Target specifies where the annotation can be used (fields, parameters, etc.).
@Retention(RUNTIME) means the annotation is available at runtime for validation frameworks.

Step 2: Implement the Validator

Now, create a validator class ConditionalNotNullValidator.

import jakarta.validation.ConstraintValidator;
import jakarta.validation.ConstraintValidatorContext;

public class ConditionalNotNullValidator implements ConstraintValidator<ConditionalNotNull, Object> {

    @Override
    public void initialize(ConditionalNotNull constraintAnnotation) {
        // You can access annotation attributes here if needed
    }

    @Override
    public boolean isValid(Object value, ConstraintValidatorContext context) {
        return value != null;
    }
}

Explanation:

The isValid method returns true if the value passes validation.
Here, we simply check if the value is not null.

Step 3: Use the Custom Annotation

Now you can use @ConditionalNotNull just like @NotNull!

public class UserDTO {

    @ConditionalNotNull(message = "Username must not be null!")
    private String username;

    @ConditionalNotNull
    private String email;

    // getters and setters
}

When you validate UserDTO, the @CondtionalNotNull constraints will automatically kick in.

Bonus: Extend It Further

You can enhance @ConditionalNotNull to:

Check for non-empty strings or collections
Add conditional validation (validate only if another field has a certain value)
Support customized error codes for better API responses

Example to check non-empty Strings:

@Override
public boolean isValid(Object value, ConstraintValidatorContext context) {
    if (value == null) {
        return false;
    }
    if (value instanceof String) {
        return !((String) value).trim().isEmpty();
    }
    return true;
}

Now @ConditionalNotNull not only checks for null but also ensures strings aren't just blank spaces!

Conclusion

Creating a custom constraint like @NotNull is straightforward but very powerful. It keeps your code cleaner, validations reusable, and applications more maintainable.

By combining annotations and validator classes, you can create any kind of validation logic tailored specifically to your project’s needs.

Why Promise.all() Isn’t Always the Best Choice for Independent API Calls

Debug Diaries — Tue, 22 Apr 2025 14:28:13 +0000

Async/await is powerful — but it’s easy to assume it magically makes your code fast and reliable. I’ve seen this first-hand in real-world scenarios.

One common issue when working with multiple API calls is sequential execution, which can lead to unnecessarily long load times. For example, consider the following code:

const response1 = await fetchA();
const response2 = await fetchB();
const response3 = await fetchC();

In this case, each API call waits for the previous one to finish before starting, which means the total response time is the sum of all the individual call times

To overcome this, we can run the API calls in parallel instead of sequentially. The solution is to use Promise.all():

const [response1, response2, response3] = await Promise.all([
  fetchA(),
  fetchB(),
  fetchC(),
]);

The total response time dropped immediately. Instead of waiting for each other, all three requests were made simultaneously.

That felt like a huge win. But here’s where things can get tricky…

The Hidden Risk with `Promise.all()`

While Promise.all() looks like the perfect solution to run tasks in parallel, it has a major caveat:

If any one of the promises rejects, the whole Promise.all() rejects — even if the other calls succeed.

For example:

const [response1, response2, response3] = await Promise.all([
  fetchA(),
  fetchB(), // let's say this fails
  fetchC(),
]);

If fetchB() throws an error, you won’t get the results of fetchA() or fetchC(), even if they succeeded. The entire batch fails.

So if your API calls are independent and you still want results from the ones that succeed, Promise.all() may not be the best fit.

The Safer Alternative: `Promise.allSettled()`

When you care about completing all tasks, regardless of success or failure, use Promise.allSettled():

const results = await Promise.allSettled([
  fetchA(),
  fetchB(),
  fetchC(),
]);

results.forEach((result, index) => {
  if (result.status === 'fulfilled') {
    console.log(`Response ${index + 1}:`, result.value);
  } else {
    console.error(`Error in API ${index + 1}:`, result.reason);
  }
});

When to Use What?

Use Promise.all() when all calls must succeed for the task to proceed.
Use Promise.allSettled() when calls are independent and can fail individually without affecting the rest.
Use individual try/catch blocks around each await call when you need granular error handling for each API response.

Final Thoughts

Async/await makes async logic cleaner, but that doesn’t guarantee efficiency or fault-tolerance. Knowing when to parallelize and how to handle failures is key.

So the next time you’re making multiple API calls:

Check if they’re independent
Decide how you want to handle partial failures
Choose Promise.all(), Promise.allSettled(), or a manual await based on that

Tiny changes. Huge impact.

✍️ Have you faced similar async challenges in your codebase? Let’s chat in the comments!

DEV Community: Debug Diaries

How ChatGPT Works (Simple Explanation for Beginners)

High-Level Flow

1. Input Processing

2. Context Building (Prompt Augmentation)

3. LLM Processing (The Brain)

4. Output Processing

Final Flow (Simplified Diagram)

Important Note

Why This Matters

What’s Next?

How a Browser Renders a Webpage — And Where React, CSR, and SSR Fit In

1. The Request Process

Step 1: Check Cache

Step 2: DNS Lookup

Step 3: Establish Connection

Step 4: Send HTTP Request

2. Server Response

3. HTML Parsing and DOM Creation

4. CSS Parsing and CSSOM

5. Render Tree Creation

6. Layout (Reflow)

7. Paint

8. Compositing

9. Where JavaScript Fits In

10. Client-Side Rendering (CSR)

User Experience

11. Server-Side Rendering (SSR)

12. Hydration

CSR vs SSR Comparison

JavaScript Explained: Set, WeakSet, Map & WeakMap – What They Are and When to Use Them

Set – A Collection of Unique Values

WeakSet – Sets with Weak References

Map – Key-Value Pairs with Powerful Features

WeakMap – Object Keys with Weak References

Final Thoughts

Understanding SOLID Principles in Frontend Development (with React Examples)

What is SOLID?

1. Single Responsibility Principle (SRP)

2. Open/Closed Principle (OCP)

3. Liskov Substitution Principle (LSP)

4. Interface Segregation Principle (ISP)

5. Dependency Inversion Principle (DIP)

Conclusion

Creating Custom Constraints: Writing Your Own @NotNull Annotation

Why Create a Custom Constraint?

Step 1: Create the Custom Annotation

Step 2: Implement the Validator

Step 3: Use the Custom Annotation

Bonus: Extend It Further

Conclusion

Why Promise.all() Isn’t Always the Best Choice for Independent API Calls

The Hidden Risk with Promise.all()

The Safer Alternative: Promise.allSettled()

When to Use What?

Final Thoughts

The Hidden Risk with `Promise.all()`

The Safer Alternative: `Promise.allSettled()`