Building Large Language Model (LLM) applications requires a different approach. Because AI models are probabilistic, small changes to a prompt, an updated model version, or a new search index can quietly change your app's responses. The app's API may still return a successful status code, but the model might give users incomplete, unhelpful, or incorrect information.

This issue makes LLM evaluation—the process of automatically testing AI output quality—a core skill for modern engineers. Instead of relying on manual spot checks, teams use structured evaluation tools to test, measure, and improve their AI systems.

Why AI Testing Is Different from Traditional Software

In regular software engineering, code is deterministic. That means giving the same input to a function always produces the exact same output:

# Traditional test: The result is always 5
def add(a: int, b: int) -> int:
    return a + b

assert add(2, 3) == 5

Large Language Models do not work this way. If you ask an LLM the exact same question twice, it can give you two different answers that are both correct. Because of this variation, simple exact-match assertions fail:

# LLM test: The text changes even if the meaning is correct
response_1 = llm.generate("Explain Docker volumes in one sentence.")

response_2 = llm.generate("Explain Docker volumes in one sentence.")

# This test will fail because the words do not match exactly
assert response_1 == response_2  # ❌ Fails

Production AI applications contain many moving parts: system prompts, temperature settings, retrieved documents, and underlying model updates. To catch quiet drops in quality, engineers must measure outputs using semantic meaning, factual accuracy, and context scores.

Connecting Traditional Testing to LLM Evaluation

You do not need to replace your existing engineering practices to work with AI. Instead, you can map familiar testing ideas directly to LLM evaluation workflows:

Core Metrics: What Should You Measure?

Not every application needs every metric, but production AI systems generally focus on three main areas: output quality, system speed, and user feedback.

1. Quality and Accuracy Metrics

• Relevance: Checks if the AI directly answers the user's question without adding unnecessary information.

• Faithfulness / Groundedness: Important for Retrieval-Augmented Generation (RAG). It confirms that the AI uses facts from the provided documents.

• Hallucination Rate: Measures how often the model creates incorrect facts or false statements.

• Correctness: Verifies if the answer matches a known, correct answer.

2. Operational Metrics

• Speed (Latency): Measures the total time taken to respond and the time to show the first word.

• Cost: Tracks how many tokens were used so API costs stay under control.

Four Common Ways to Evaluate AI Answers

Engineers use four main methods to measure AI response quality, balancing cost, speed, and accuracy:

1. Rule-Based Matching: Uses simple checks like regular expressions or JSON schemas. It is fast, free, and works well for structured data.

2. Semantic Similarity: Converts sentences into mathematical numbers (vectors) to see if two phrases mean the same thing, even if they use different words.

3. LLM-as-a-Judge: Uses an advanced model (like GPT-4o or Claude) to read responses and give them scores based on set instructions.

4. Human Review: Subject matter experts check outputs by hand. This method is slow and expensive, but it remains important for sensitive areas like medical, legal, or financial tools.

Evaluating RAG Systems: The RAG Triad

Retrieval-Augmented Generation (RAG) apps pull information from a database before answering questions. If a RAG app gives a bad answer, the problem could come from the document search step or the text generation step.

To find the source of the error, engineers evaluate the RAG Triad:

• Context Precision & Recall: Checks if the search tool found the right documents without including useless information.

• Faithfulness: Confirms that the AI only used facts from the retrieved documents.

• Response Relevance: Confirms that the generated answer answers the user's initial question.

Popular LLM Evaluation Frameworks

Different evaluation tools fit different parts of your engineering workflow:

Building a "Golden Dataset"

Just like traditional software relies on test files, AI testing relies on a Golden Dataset. This is a clean set of sample user questions, reference documents, and expected answer guidelines that you use for testing.

[
  {
    "test_id": "eval_001",
    "user_input": "How do I save data in Docker after stopping a container?",
    "retrieved_context": ["Docker volumes keep data safe even when containers stop."],
    "expected_behavior": "Explain Docker volumes clearly with simple terminal commands.",
    "eval_metrics": ["faithfulness", "relevance"]
  },
  {
    "test_id": "eval_002",
    "user_input": "What is our company policy on software refunds?",
    "retrieved_context": [],
    "expected_behavior": "Politely state that context is missing instead of making up a policy.",
    "eval_metrics": ["hallucination_prevention"]
  }
]

Simple Steps to Build Your Dataset

1. Start Small: Write 20 to 50 test cases covering your core product features.

2. Use Real Production Data: Collect real questions and negative user feedback (like thumbs-down clicks).

3. Turn Bugs into Tests: Whenever a user finds a bad response, turn that question into a new test case so the mistake never happens again.

When Should You Add Evaluation to Your Project?

Adding complex testing too early can slow you down, but waiting too long can lead to bad user experiences. Match your testing strategy to your project size:

Evaluation vs. Observability

While these two terms sound similar, they serve different purposes in engineering:

• Evaluation answers: "Is my AI application giving good, safe answers during testing?"

• Observability answers: "Why did the AI app slow down or give bad answers at 2:00 AM in production?"

If your evaluation scores drop, observability tools (like step-by-step logs and latency charts) help you find the exact cause—whether it is a slow database, an API outage, or a bad system prompt.

Best Practices for Engineers

• Use Multiple Metrics: Do not rely on a single score. Combine simple rule checks with LLM judges to catch different kinds of mistakes.

• Version Your Assets: Keep your prompt templates, test datasets, and code together in version control like Git.

• Automate Testing: Run your test suite automatically whenever an engineer opens a pull request to update prompts or code.

• Watch Speed and Cost Together: High answer quality is not helpful if your API bills are too expensive or your app takes too long to load.

Final Thoughts

LLM evaluation is not about getting a 100% score on every single prompt. It is about building confidence in your software.

Just as automated unit testing became standard practice for classical software engineering, evaluation is now essential for building AI applications. By replacing guesswork with regular automated tests, you can fix bugs early, improve performance, and deliver AI tools that users can trust.

But what if your app only gets used a few times a day? You are still paying for that server every single second it sits idle.

This is where AWS Lambda comes in.

AWS Lambda is a serverless service. "Serverless" doesn't mean there are no servers; it just means you don't have to manage them. You don't have to set up an operating system, install updates, or worry about hardware. You simply upload your code, and AWS runs it only when it's needed.

In this guide, we will look at the core concepts of Lambda by building, deploying, and running a simple Python function right inside your browser.

The Core Concept: Pay-As-You-Go Code

Think of traditional servers like renting an apartment—you pay rent every month whether you are sleeping there or away on vacation.

AWS Lambda is like a hotel room—you pay only for the exact time you are using it.

Why do software engineers love it?

• Zero Maintenance: You focus 100% on writing Python code. AWS handles the cloud infrastructure.

• Massive Cost Savings: If your code isn't running, your bill is exactly $0. AWS charges you only for the milliseconds your code takes to execute.

• Automatic Growth: If 1 person uses your code, it runs once. If 1,000 people use it at the exact same time, AWS automatically creates 1,000 copies to handle the demand.

Prerequisites

To follow along, you only need two things:

1. An active AWS Account (The AWS Free Tier includes 1 million free Lambda requests per month!).

2. Basic knowledge of Python (knowing how to write a simple function).

Step-by-Step: Building Your First Function

Step 1: Find Lambda in the AWS Console

1. Log into your AWS Management Console.

2. Type Lambda into the search bar at the top of the screen.

3. Click on Lambda from the search results to open the dashboard.

4. Click the orange Create function button.

Step 2: Configure Your Function

AWS will give you a few options. Keep it simple and select Author from scratch.

Fill out the basic settings like this:

Scroll to the bottom and click the orange Create function button.

Step 3: Look at the Python Code

Once your function is created, AWS will show you a built-in code editor. Inside, you will see a file containing a basic Python function that looks like this:

def lambda_handler(event, context):
    return {
        'statusCode': 200,
        'body': 'Hello from AWS Lambda!'
    }

Let's break this down into simple terms:

• def lambda_handler(...): This is the main entry point. Think of it like the main() function or the first line of code AWS looks for when it runs your file.

• event and context: These are placeholders (variables) that AWS automatically passes into your function. For now, you don't need to use them. Just know they represent information being sent to your function when it runs.

⚠️ Troubleshooting Note: Seeing a "Unable to retrieve source code" error? If the built-in AWS code editor displays an error saying it cannot load or retrieve your source code, don't panic! This is usually caused by an aggressive browser extension (like an ad-blocker or privacy shield) blocking the AWS network requests. How to fix it quickly:

• The Easy Way: Try turning off your browser's ad-blocker for the AWS Console, or open the AWS Console in an Incognito / Private window.

• The Professional Way: If you prefer working locally, you can skip the browser editor entirely. You can write your Python code on your computer using VS Code, package it into a standard .zip file, and upload it to Lambda using the Upload from dropdown button on this exact same page.

Step 4: Change and Deploy Your Code

Let's make a slight change to the code so you can see how editing works. Update the text to include a simple Python print statement:

def lambda_handler(event, context):
    print("Testing my first cloud function!")
    
    return {
        'statusCode': 200,
        'body': 'Success! My Python code is running in the cloud.'
    }

💡 Important Step: Just like saving a file on your computer, you must tell AWS to save your changes to the cloud. Click the Deploy button right above the code editor. Your code is now live!

Step 5: Test Your Function

Since we don't have a website or mobile app connected to this yet, AWS provides a way to simulate running it.

1. Click the Test button next to Deploy.

2. A window will pop up asking you to create a "Test event". Don't worry about the complex text on the screen; just type MyFirstTest in the Event name box.

3. Scroll down and click Save.

4. Now, click that Test button one more time.

Look at the Execution result box that appears! You will see the successful response:

{
  "statusCode": 200,
  "body": "Success! My Python code is running in the cloud."
}

Where do my print statements go? (CloudWatch Logs)

In a normal Python script on your computer, print() outputs text directly to your terminal screen. But where does it go when it runs on a server thousands of miles away?

It goes to Amazon CloudWatch.

CloudWatch is AWS's digital notebook. Every single time your Lambda function runs, it automatically writes down what happened.

If you click on the Monitor tab right below your function name, and then click View CloudWatch Logs, you will see a history of when your function ran, how long it took, and your custom message: Testing my first cloud function!. This is how you will debug your code when things go wrong in the future.

Next Steps: Moving Beyond the Basics

Now that you understand how to write, deploy, and test code on AWS Lambda, you are familiar with the foundation of serverless computing!

As you get more comfortable, you can start exploring how to connect your Lambda function to the rest of the world. For example:

• Triggers: You can tell Lambda to run automatically whenever someone uploads a picture to an online storage bucket (S3 Bucket), or on a timer (like a daily alarm clock).

• API Gateway: You can connect Lambda to a web address so that anytime a user visits [yourwebsite.com/api](https://yourwebsite.com/api), your Python code fires up and sends back data.

Conclusion

You don't need to be a cloud architect to start using the cloud. In just a few minutes, you managed to:

1. Create a managed Python environment.

2. Write and save live cloud code.

3. Execute it and view the output.

The best way to learn is by experimenting. Try changing the text inside the body return statement, hitting Deploy, and testing it again!

So, you open the AWS Console, click through a dozen complex menus, create an Amazon S3 bucket, wire up an AWS Lambda function, configure security permissions… and somewhere along the way, you miss a single toggle. You then spend the next 45 minutes guessing why nothing works.

Then comes the real nightmare: you have to do the exact same manual clicking all over again for your production environment.

There is a much better way. It’s called AWS CDK.

What Is AWS CDK?

The AWS Cloud Development Kit (CDK) is an open-source framework that lets you define your cloud infrastructure using familiar programming languages like TypeScript, Python, Java, Go, or C#.

Instead of clicking around a dashboard or writing massive JSON configuration files, you write clean code like this:

const bucket = new s3.Bucket(this, 'UploadsBucket');
const fn = new lambda.Function(this, 'Processor', { ... });

// Permissions are handled automatically!
bucket.grantRead(fn);

With a single terminal command, AWS builds your bucket, configures your Lambda function, and wires up the exact security permissions automatically.

The Engine Under the Hood: AWS CloudFormation

To understand how CDK works, you need to know about AWS CloudFormation.

CloudFormation is AWS’s native tool for creating resources using text files (written in JSON or YAML). It’s incredibly powerful, but writing thousands of lines of raw configuration files by hand is exhausting and error-prone.

This is where AWS CDK comes in. You write your infrastructure in standard programming languages, and the CDK Synthesizer acts as a translator. It takes your code and compiles ("synthesizes") it into standard CloudFormation templates automatically. You get the power of CloudFormation without ever having to write a single line of JSON or YAML.

Why Not Just Use the Console?

The AWS Console is fine for quick experiments. However, it completely falls apart the moment you need to:

• Recreate environments: Setting up separate spaces for testing, staging, and production.

• Track history: Knowing exactly who changed a database setting and when.

• Recover from errors: Quickly rebuilding your setup if something breaks.

• Onboard teammates: Getting a new developer's environment running without errors.

With AWS CDK, your entire cloud infrastructure lives inside a Git repository. It is fully reviewable, repeatable, and rollback-able. You use one command to deploy everything, and one command to tear it all down cleanly.

The 4 Core Concepts You Need to Know

Before writing code, it helps to understand the four main building blocks of CDK:

• App: The main entry point of your CDK program. Everything else lives inside the App.

• Stack: A collection of cloud resources deployed together as a single unit. Most projects use a few stacks (e.g., one stack for the database, one for the API, one for storage).

• Construct: The basic building blocks. A single S3 bucket is a construct. A Lambda function is a construct. You can even group smaller constructs together into a custom, reusable component.

• Synth (Synthesize): The translation step. You write your infrastructure in standard programming languages, but AWS requires CloudFormation (YAML or JSON templates) under the hood. The synth command automatically translates your code into these cloud templates for you.

Setting It Up

# 1. Install AWS CDK globally
npm install -g aws-cdk

# 2. Bootstrap CDK with your AWS Account (Run this once per region)
cdk bootstrap aws://YOUR_ACCOUNT_ID/YOUR_REGION

# 3. Initialize a new project directory
mkdir my-cdk-app
cd my-cdk-app
cdk init app --language typescript

Note on Bootstrapping: The cdk bootstrap command only needs to be run once per AWS account/region. It sets up a secure storage backend that CDK requires to deploy your future projects.

A Real Example

Here is a complete TypeScript example creating an S3 bucket, a Lambda function, and giving the function permission to read files from that bucket. This covers the foundation of most modern cloud backend systems:

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as lambda from 'aws-cdk-lib/aws-lambda';

export class MyAppStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 1. Create a secure S3 Bucket
    const bucket = new s3.Bucket(this, 'UploadsBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Deletes bucket when stack is destroyed
    });

    // 2. Create a Node.js Lambda Function
    const processor = new lambda.Function(this, 'Processor', {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'), // Points to a 'lambda' local folder
      environment: { BUCKET_NAME: bucket.bucketName },
    });

    // 3. Grant explicit read permission safely
    bucket.grantRead(processor);
  }
}

Look closely at the bucket.grantRead(processor); line. This single phrase replaces dozens of lines of complex Identity and Access Management (IAM) security policies that you would normally have to type out manually.

How to Deploy Your Infrastructure

Once your code is written, you manage your deployments using three core commands:

# Preview exactly what changes will happen in AWS
cdk diff 

# Safe deployment of your code directly to AWS    
cdk deploy  

# Delete all resources safely to avoid unexpected costs 
cdk destroy  

The cdk diff command is incredibly helpful. Before anything alters your active AWS account, the terminal displays exactly what resources will be added, modified, or deleted.

Where CDK Shines in Production

• Identical Environments: Staging and production configurations share the exact same code blocks. They never drift apart due to human error.

• Fast Onboarding: A new developer can clone your project repository, run cdk deploy, and build an entire development cloud playground in minutes. No outdated text guides required.

• Microservices Made Simple: Your backend code and its infrastructure settings live in the very same code repository. They ship together inside the same pull request.

Pro-Tip: CloudFormation Limits

Because CDK compiles into AWS CloudFormation under the hood, it shares CloudFormation limits—including a maximum of 500 resources per stack. While small or mid-sized applications rarely hit this limit, it is best practice to group separate business domains into unique Stacks early on as your application expands.

The Bottom Line

The AWS Console is a fantastic place to explore services. It is a terrible place to manage production infrastructure.

AWS CDK transforms your cloud architecture into software that is versioned, testable, and completely predictable. Once you shift your infrastructure management into clean code files, returning to manual dashboard clicking feels like manually typing SQL strings directly into a terminal instead of using a modern ORM.

One of the most common misconceptions among developers is that adding more application servers automatically means the application can handle more users. Unfortunately, that's not how it works.

In this article, you'll learn why databases eventually become the bottleneck as your system grows, how replication improves read-heavy workloads, and when sharding becomes the only way forward.

The Database Bottleneck

Imagine you're running a library.

At first, there's one librarian. A handful of visitors arrive each hour — they ask for books, return borrowed ones, or register for new memberships. Everything runs smoothly.

Now imagine the library becomes wildly popular. Instead of ten visitors per hour, hundreds arrive every minute.

You hire more receptionists to greet them. That's essentially what adding more application servers does.

But here's the problem: every receptionist still has to walk to the same librarian every time someone needs a book.

Eventually, the receptionist isn't the bottleneck anymore. The librarian is.

Databases work exactly the same way.

No matter how many application servers you add, they all talk to the same database. Every request that needs to fetch user data, place an order, update a profile, or process a payment ends up reaching that one database.

At some point, the database simply can't keep up — not because databases are slow, but because every machine has limits.

Why Does the Database Slow Down?

Every database operation consumes resources.

Reading data requires CPU time, memory, and disk access. Writing data demands even more — the database must validate constraints, update indexes, write to storage, and confirm the data is safely persisted.

As traffic grows, so does the work. And adding more application servers can actually make things worse, because you've increased the number of clients hammering the same database simultaneously.

There are two common strategies to address this:

• Replication — when reading data is the bottleneck

• Sharding — when a single database can no longer handle the overall workload

They look similar on the surface, but they solve very different problems.

Database Replication

Suppose your application receives thousands of requests per minute. If you look closely, most of them are simply reads — users browsing products, viewing profiles, searching posts, or checking order history. Very few requests actually modify data.

So why should one database handle every single read?

The answer is: it doesn't have to.

Database replication means creating multiple copies of the same database. One database is designated the primary — it receives all write operations. The additional databases, called replicas or read replicas, continuously copy data from the primary and handle read requests.

Going back to the library analogy: instead of one librarian answering every question, you now have several librarians, each with an identical copy of every book. Visitors can be served simultaneously without anyone waiting in a long queue.

The Catch: Replication Lag

Replication sounds perfect — but it introduces an important trade-off.

Replicas are not updated instantly. There's usually a small delay between when the primary receives a write and when the replicas reflect that change. Most of the time this delay is just a few milliseconds, which is perfectly acceptable for most applications.

But consider this: you update your profile picture and immediately refresh the page. If that request is routed to a replica that hasn't synced yet, you might briefly see your old photo. This delay is called replication lag.

Understanding this trade-off matters more than knowing the technology itself. The right question isn't "Can I use replication?" It's "Can my application tolerate slightly stale data?"

If the answer is yes, replication is a great solution.

When Replication Isn't Enough

Replication improves read performance. But every write still goes to the same primary database.

For applications with heavy write workloads — think banking systems, messaging platforms, ride-sharing apps, or payment gateways — write traffic alone can overwhelm that primary node. Adding more read replicas does nothing to help here.

When the bottleneck shifts to writes, you need a fundamentally different strategy.

Instead of copying the database, you split it.

Database Sharding

Imagine the library has grown into the largest in the country. Hiring more librarians isn't enough anymore — there's simply too much information in one place.

So you build multiple libraries. One stores books from A–H. Another covers I–P. The third holds Q–Z. Visitors don't browse every library — they go directly to the one that has what they need.

Database sharding works the same way. Instead of storing all your data in a single database, you divide it into smaller pieces called shards. Each shard holds only a portion of the data.

For example:

• Users A–H → Shard 1

• Users I–P → Shard 2

• Users Q–Z → Shard 3

Now writes are spread across multiple databases. No single node bears the full load.

Replication vs. Sharding: Key Differences

These two techniques are often mentioned together, but they address different layers of the scaling problem:

In large-scale systems, the two are often used together — each shard can have its own set of read replicas, giving you both write scalability and read distribution at the same time.

Final Thoughts

The most important lesson in system design isn't which technology to use — it's understanding which problem you're actually solving.

Replication improves reads but accepts that data may be slightly out of date. Sharding improves write capacity but adds complexity to your architecture. Neither is universally better. They're answers to different questions.

The goal isn't to build the most sophisticated system possible. It's to identify the bottleneck clearly, and apply the simplest solution that removes it.

Your users send requests, the server processes the backend logic, talks to the database, and returns a response. For early-stage projects or low-traffic MVPs, this setup works perfectly.

But successful applications rarely stay static. As more concurrent users start using your product, the sheer volume of requests increases. At some point, the server reaches its physical resource limits, and simply writing cleaner code or optimizing queries is no longer enough.

To keep your application responsive under heavy traffic, you need to scale.

Every Server Has a Hardware Limit

To understand why a single server fails under load, think of it like a one-person fast-food drive-thru. The lone employee has to take the order, cook the food, bag it, and process the payment. If only a few cars show up an hour, the workflow is seamless.

But what happens when hundreds of cars arrive simultaneously? The queue wraps around the block, customers face long wait times, and people eventually leave out of frustration.

In the digital world, a single server faces the exact same physical constraints. Every request your application handles consumes a finite slice of infrastructure hardware:

• CPU: Brainpower required to execute application logic and serialize data.

• RAM: Execution memory needed to hold state and application contexts during runtime.

• Network Bandwidth: The throughput capacity required to handle concurrent incoming and outgoing packets.

• Disk I/O: The speed at which your application reads from or writes to persistent storage.

When traffic spikes, these physical resources hit 100% utilization. As a result, requests pile up in the network stack, response times degrade, and users experience timeouts or explicit HTTP errors. This failure isn't due to bad code—it's a fundamental hardware limitation.

Scaling: Vertical vs. Horizontal

When a single server hits its ceiling, you have to increase your infrastructure's capacity. This is known as scaling, and there are two primary pathways to achieve it.

1. Vertical Scaling (Scaling Up)

In our drive-thru analogy, vertical scaling is like replacing your lone employee with a world-class super-chef.

[ 4 CPU, 8 GB RAM ] ───( Upgrade Instance Type )───> [ 16 CPU, 64 GB RAM ]

You keep your single-server setup but upgrade the underlying hardware through your cloud provider—adding more CPU cores, expanding RAM, or moving to faster storage.

While this requires zero changes to your application architecture, it creates a Single Point of Failure. If that single machine crashes, your entire app goes offline. Furthermore, you will eventually hit a hard physical ceiling—the largest instance type your cloud provider offers—where further upgrades become prohibitively expensive.

2. Horizontal Scaling (Scaling Out)

Instead of making one server larger, horizontal scaling is like opening three more drive-thru lanes and hiring three more employees.

You deploy identical copies of your application across multiple, independent servers to share the workload. This builds redundancy into your system; if Server 1 suffers a hardware failure, Server 2 and Server 3 continue handling requests. This approach offers near-infinite scalability and is the blueprint for modern web infrastructure.

Comparison Between Horizontal and Vertical Scaling

More Servers Create a Routing Problem

While horizontal scaling solves the capacity issue, it introduces an immediate architectural challenge. Imagine your application is now running across four separate servers. A user types your URL into their browser. Which backend server should handle that specific request? The browser doesn’t know. While DNS maps a domain name to an IP address, basic DNS isn't dynamic enough to distribute traffic evenly based on real-time server loads. To bridge this gap, you need a dedicated traffic coordinator. This is where Load Balancers come in.

What Is a Load Balancer?

A Load Balancer acts as a traffic manager that sits directly in front of your server pool, serving as the singular public entry point for all incoming traffic.

Instead of clients communicating directly with individual application instances, every request hits the load balancer first. It evaluates the current state of your backend cluster and routes the request to the optimal server.

To the end-user, the architecture is entirely invisible. They interact with a single domain, while behind the scenes, the load balancer prevents any single server from becoming a bottleneck.

How the Load Balancer Distributes Traffic

Load balancers rely on specific routing strategies, or algorithms, to distribute requests efficiently:

• Round Robin: The simplest method. Requests are handed out sequentially across the pool (Server 1, then Server 2, then Server 3) in a continuous loop.

• Least Connections: A dynamic approach. The load balancer tracks active connections and automatically directs new traffic to the server currently handling the lightest workload.

• Health Checks: The load balancer continuously monitors your backend instances via automated ping requests. If a server stops responding or throws errors, the load balancer instantly pulls it from the pool, preventing users from experiencing broken pages.

Conclusion

Most applications don't need a multi-server distributed architecture on day one. Introducing load balancing too early simply adds unnecessary operational complexity.

Good engineering is about choosing the simplest architecture that satisfies your current requirements while keeping a clear path for future expansion. Once your application layer genuinely outgrows a single machine, a load balancer paired with a horizontally scaled cluster is your definitive next step.

Understanding that process is one of the first building blocks of system design.

Let's start with a simple question: what happens when you type google.com into your browser?

The Problem: Computers Don't Understand Names

Computers communicate using IP addresses, not domain names.

For example:

142.250.190.78

An IP address is like a street address. It tells the internet exactly where a server lives.

The problem is obvious. Remembering google.com is easy. Remembering 142.250.190.78 is not.

That's why domain names exist.

What Is DNS?

DNS stands for Domain Name System.

Think of it as the internet's phonebook.

You provide a name:

google.com

DNS returns an address:

142.250.xxx.xxx

Without DNS, every website would need to be accessed by its raw IP address. The modern internet would be unusable.

How DNS Resolution Works

When you type google.com, your browser first checks:

"Do I already know the IP address for this?"

If not, it starts a DNS lookup:

Browser
   ↓
DNS Resolver (usually your ISP)
   ↓
Root Name Server
   ↓
TLD Name Server (.com)
   ↓
Authoritative Name Server (google.com)
   ↓
IP Address returned to browser

Once the browser has the IP address, it knows exactly where to send the request.

This entire process typically completes in milliseconds.

Why DNS Caching Matters

Every DNS lookup takes time. If your browser had to repeat this process on every request, the internet would feel noticeably slower.

To solve this, DNS responses are cached at multiple levels:

• Browser cache — your browser stores recent lookups

• Operating system cache — your OS keeps its own DNS records

• ISP cache — your internet provider caches lookups across all its users

When your browser already knows google.com → 142.250.xxx.xxx, it skips the lookup entirely.

This is why websites often load faster on the second visit.

Why This Matters for System Design

Most engineers never think about DNS until something breaks.

But DNS sits at the very beginning of every request your users make. Understanding it helps you reason about:

• Why a website becomes unreachable even when your server is running fine

• Why DNS outages can take down entire companies

• Why latency exists before a request even reaches your application

• How traffic gets routed to the correct server across the globe

DNS is also the foundation for more advanced concepts like load balancing, failover, and CDN routing.

Before any of that complexity kicks in, a simple lookup has already happened. Silently. In milliseconds. Every single time.

But when designing scalable backend systems, the real question isn't "Which messaging tool should I use?"

The real question is: "What architectural problem am I actually trying to solve?"

The Monolith Problem: A Simple Example

Imagine you are building a standard e-commerce application. When a customer clicks "Place Order," several distinct processes need to trigger across your system:

• Save the order details to the database

• Send a customer confirmation email

• Update the inventory count

• Generate a PDF invoice

• Notify the warehouse shipping team

• Update the real-time analytics dashboard

When building an early-stage monolith architecture, many development teams structure the backend code like this:

Order Service
 ├── Save Order (Database Write)
 ├── Send Email (SMTP Call)
 ├── Update Inventory (Stock Service)
 ├── Generate Invoice (Billing Service)
 ├── Notify Warehouse (Fulfillment Service)
 └── Update Analytics (Data Pipeline)

At first, this direct, synchronous approach works perfectly. But as the business grows, more third-party integrations appear, and more microservices are added to the codebase.

Suddenly, the Order Service knows way too much about every other system. A single order placement becomes tightly coupled to multiple external dependencies. If the email provider flakes or the analytics pipeline experiences latency, the entire checkout process chokes or crashes for the user.

Visualizing Tight Coupling in Microservices

Here is how direct API calls create dependency hell as an application scales:

The Core Concept: Shifting to Events

The fundamental rule of clean system design is separation of concerns. The Order Service shouldn't care how the inventory management system works. It shouldn't care how transactional emails are queued, and it definitely shouldn't care how backend analytics are calculated.

Its only job is to process the transaction. Once the order is validated, it should simply state a fact: An order was placed.

Everything else that happens afterward is just a consequence of that historical event.

This is where Event-Driven Architecture completely changes the paradigm. Instead of directly calling five different APIs synchronously, the Order Service broadcasts an immutable message—an event—called OrderPlaced.

It drops this message directly into an Event Bus (also known as a Message Broker).

📬 What is an Event Bus? Think of it as a digital post office. The Order Service just drops off the mail and leaves. It doesn't care how the mail gets sorted or when it gets delivered; its job is done, allowing it to immediately serve the next customer.

Other independent background services subscribe to this specific event channel. Each microservice reacts completely independently. The Order Service doesn't know—and doesn't need to know—who is listening on the other side of the event broker.

Visualizing Asynchronous Event Flow

By introducing an event bus, we completely decouple the publisher from the consumers:

Why Companies Adopt Event-Driven Architecture

When transitioning from a monolith to distributed systems, implementing an event-driven pattern offers four massive advantages for technical teams:

1. Loose Coupling

Services become entirely autonomous. The Order Service will never break or experience downtime just because the team managing the Analytics Service pushed a breaking change to their deployment.

2. Independent Scalability

Different backend workloads experience different architectural strains. Your data analytics engine might need to process millions of minor tracking events, while your email service only handles a few thousand messages. An event broker allows you to scale the infrastructure for individual components based on their specific resource needs.

3. Frictionless Integrations

What happens if your business decides to add a new AI-driven fraud detection service? Instead of modifying, testing, and redeploying the core Order Service code, you simply tell the new fraud detection microservice to subscribe to the existing OrderPlaced event stream.

4. High Fault Tolerance and Resilience

If your analytics database crashes or goes offline for maintenance, user orders can still be placed without interruption. The event broker safely stores the OrderPlaced messages in a queue. Once the analytics service recovers, it simply picks up right where it left off, processing the backlog without losing a single byte of data.

Event-Driven Architecture vs. Monolith: When Do You Actually Need It?

A classic mistake made by engineering teams is spinning up a complex Kafka cluster on Day 1. Most software applications do not require the overhead of a distributed event broker initially.

You should realistically consider moving to an Event-Driven Architecture only when:

• Multiple distinct systems need to react to the exact same business trigger.

• Your external third-party integrations are constantly increasing.

• Specific microservices require entirely independent infrastructure scaling.

• Tight code coupling is actively slowing down your team's deployment velocity.

• Asynchronous processing is perfectly acceptable for the end-user experience.

Senior Reminder: Notice that none of these core engineering problems explicitly mention tools like Kafka or RabbitMQ. The architectural bottleneck must appear first; the choice of technology comes second.

When to Avoid Event-Driven Architecture

Sometimes, a standard, synchronous HTTP API call is still the best engineering tool for the job. Avoid adding the complexity of an event bus when:

• The application is small, or you are still in the early MVP validation phase.

• Your backend workflows are straightforward and linear.

• The system demands immediate, synchronous, real-time responses.

• The operational complexity of managing queues outweighs any architectural benefit.

Introducing a message broker too early forces your team to manage distributed system bugs (like out-of-order messages, network partitions, and duplicate events) before you actually have a scaling problem.

Visualizing the Complexity Trade-off

Choosing the right architectural pattern depends entirely on your current scale:

The Senior Engineer Mindset

Junior/Mid-level developers often ask technical questions centered on tools: "Should we use Kafka or AWS SQS for this project?"

Senior engineers shift the focus entirely to the underlying system constraints: "What specific problem are we trying to solve by introducing asynchronous messaging?"

Ultimately, Event-Driven Architecture isn't about specific technologies. It is an intentional design philosophy focused on reducing system coupling, improving scalability, and allowing backend applications to evolve over time. The technology you pick is just an implementation detail—the structural thinking is what actually matters.

Final Thought

Before you introduce complex infrastructure to your stack, ask yourself: "What breaks tomorrow if we keep this design simple today?" If the honest answer is "nothing," then the simplest solution is always the best engineering choice.

But in real engineering, systems don’t begin with these decisions. They begin with a simple product idea and an urgent need to ship something quickly.

Systems don’t start as “architectures.” They start simple, and architecture emerges as they scale. Once you see this evolution, each architectural style becomes a practical response to a specific kind of pressure—not just a theoretical choice.

The MVP Phase: Start Simple, Learn Fast

Every product starts as an MVP (Minimum Viable Product). At this stage, the goal is validation, not technical perfection. You are trying to answer basic business questions:

• Do users actually want this?

• Does the product solve a real problem?

• What should we build next?

Because of this, teams optimize for fast development cycles, minimal coordination overhead, and rapid iteration.

Most MVP systems are built as a monolith—a single backend codebase, one database, and one single deployment unit where all the core business logic is bundled together.

Important: This is not “bad design.” It is the most efficient, pragmatic setup when requirements are still unclear and changing daily.

Modern Reality: Frontend and Backend Evolve Differently

Today’s systems are rarely symmetric. The frontend and backend move at different speeds and handle entirely different constraints.

1. Frontend: Naturally Modular by Default

Modern frontend systems are inherently modular out of the box. They are built using frameworks like React or Next.js and structured around isolated components, pages, and routes.

They are deployed independently via CDNs (Content Delivery Networks—servers distributed globally to deliver files fast) or edge platforms that run code closer to the user.

In large-scale companies, this goes even further:

• Micro-frontends: Splitting the UI so different teams can deploy the checkout page and the user profile completely independently.

• BFF (Backend-for-Frontend) layers: A tiny, custom API layer built specifically to format data nicely for the mobile app or web app, saving the frontend from making ten different API calls.

In practice, because of modern deployment tools, the frontend often behaves like a distributed system much earlier than the backend does.

2. Backend: Stability and Consistency First

Backends evolve more conservatively because they hold the keys to the castle: data consistency, core business logic, and transactions.

Most backend systems start with frameworks like Python (Django, FastAPI), Node.js (Express, NestJS), or Java (Spring Boot). They remain monolithic longer because debugging distributed systems is incredibly hard. Operational overhead increases the second you add more servers, and early-stage teams are usually too small to handle that complexity.

So, while the frontend becomes modular early on, the backend typically stays centralized until real scaling pressure forces a change.

When the Monolith Starts to Break

As systems grow, the monolith starts showing friction. This isn't because it was poorly designed; it’s because the context has changed.

Common signals of system strain:

• Team Friction: Multiple teams are stepping on each other's toes inside the exact same codebase, causing constant git merge conflicts.

• Deployment Bottlenecks: A tiny bug fix in the shipping module requires testing and redeploying the entire system, making deployments slow and risky.

• Scaling Inefficiency: The video processing feature needs massive CPU power, but because it’s trapped inside the monolith, you have to duplicate the entire backend on expensive servers just to scale that one feature.

At this point, architectural changes stop being an academic preference. They become a survival necessity.

The 5 Stages of Architecture Evolution

Real systems rarely jump straight from a simple monolith to a massively complex Google-level microservices cluster. Instead, they progress through gradual stepping stones:

• 1. The Monolith (MVP Stage): A single codebase and database. It’s the fastest, cheapest way to validate an idea and ship.

• 2. The Modular Monolith: The system is still deployed as one single unit, but the code inside is strictly separated into clean, isolated domains (e.g., the Payment code cannot directly access the Inventory database tables without a formal internal interface). This makes it incredibly easy to maintain and refactor later.

• 3. The Service Extraction Phase: The team takes one specific, high-strain domain (like video processing or payment handling) and splits it out into its own independent service, while leaving the rest of the application inside the core monolith.

• 4. Microservices Architecture: The system becomes a collection of highly autonomous, independent services with separate databases and separate deployments. This unlocks massive team speed but requires mature DevOps, deep monitoring, and infrastructure automation.

• 5. Event-Driven Systems: Instead of services calling each other directly and waiting for a response (which creates a chain of dependencies), they communicate asynchronously by publishing events to an event broker like Kafka or RabbitMQ. Components become completely decoupled.

What Real Systems Look Like Today

In production, most successful companies run hybrid architectures, not pure textbook patterns. A typical modern setup looks like a mix of everything:

• Frontend: React / Next.js apps deployed independently on the edge.

• Backend: A solid modular monolith handling 80% of the standard business logic, with 2 or 3 isolated microservices handles high-scale domains.

• Async Layer: A message queue or event broker (like Kafka or AWS SQS) handling background tasks.

• Data Layer: A combination of PostgreSQL for core user data, Redis for fast caching, and Elasticsearch for fast text searching.

This hybrid nature is completely intentional. Real systems evolve pragmatically—not ideologically.

The Key Takeaway

Architecture is not a static choice you make on Day 1 and live with forever. It is a continuous response to scaling pressure, team structures, and system complexity.

Instead of asking: “Which architecture should I use?”

A much better, more senior question is: “Where is the system creating friction today, and what is the smallest structural change I can make to reduce it?”

This exact mindset is what separates theoretical system design knowledge from real-world engineering judgment.

But the moment you add an AI model (like an LLM) to your app, that predictability breaks. You aren't calling a standard piece of code anymore; you are dealing with a system that guesses the next word.

That changes how you have to build your software.

The Big Shift: "Using AI" vs. "Engineering AI Systems"

When most developers start out, they just make a simple API call:

response = llm.generate(prompt)

It looks like a normal function, but in the real world, LLMs behave like a messy external service. At scale, they bring a lot of headaches:

• They freeze or time out: Responses can take seconds or fail entirely.

• They break rules: They make things up (hallucinate) or send back bad data formats.

• They get expensive: High traffic can lead to massive, unexpected bills.

Moving from a basic demo to a real product means you have to stop treating AI like a simple function and start treating it like unpredictable infrastructure.

How LLMs Compare to Traditional Software

Because AI models are unpredictable, you have to build your system assuming they will fail.

Here is how standard tech compares to AI tech:

How to Fix "Retry Storms"

When an LLM takes too long, a basic app will immediately try calling it again. If that fails, it tries again.

Before you know it, one user request turns into dozens of automatic retries:

1 Request → 3 Retries → 9 Retries → 27 Retries

If thousands of users are on your app, your system will accidentally flood the AI provider with traffic. This makes the outage worse and gets your account blocked.

The Fix: Wait and Stagger

Instead of retrying immediately, smart systems do two things:

1. Back off: Wait a bit longer between each try (like 1 second, then 2 seconds, then 4 seconds).

2. Add Jitter (Randomness): Don't let every computer retry at the exact same second. Make them wait a random amount of time (like 3.2 seconds or 4.5 seconds). This spreads out the traffic so your servers don't crash all at once.

Why You Need Message Queues

In a basic app, a user clicks a button and waits on the screen while the AI thinks. If the AI is slow, the whole app grinds to a halt.

To fix this, companies use Message Queues (like Amazon SQS or RabbitMQ). Think of it like a waiting line at a fast-food restaurant:

User Request → Waiting Line (Queue) → Workers → AI Processes It → Saved to Database

Instead of making the user stare at a loading spinner, the app takes the request, puts it in line, and lets background workers handle the AI processing. This protects your app from crashing when traffic spikes.

Real-Time vs. Batch: When to Use Which

You don't need to run every single AI task instantly. Splitting your tasks saves money and keeps your app fast.

Real-Time AI

• Best for: Chatbots, live helpers, typing assistants.

• The Catch: It’s hard to keep fast, and expensive when a lot of people use it at once.

Batch AI (In Groups)

• Best for: Summarizing long files overnight, sorting data, creating search tags.

• The Benefit: It’s way cheaper, handles errors gracefully, and runs when your servers are quiet.

The Core Problem: Speed vs. Quality vs. Cost

With normal code, making it faster doesn't make it more expensive. With AI, everything is connected in a three-way balancing act:

$$\text{Speed} \longleftrightarrow \text{Quality} \longleftrightarrow \text{Cost}$$

• If you want better quality, you need a bigger model, which is slower and costs more.

• If you want it cheaper, you use a smaller model, but the quality drops.

• If your app slows down by even half a second, requests pile up, your servers work harder, and your bill goes up.

Testing and Monitoring AI Is Way Harder

If a normal app breaks, it usually throws a clear error code (like 404 Not Found).

An AI app can look like it worked perfectly, give you a successful code, but send back completely wrong information or broken text.

Watching the App

You can't just check if your servers are turned on. You have to track:

• Which version of the prompt you used.

• How many words (tokens) the AI spent.

• How often the AI sends back broken data.

Testing the Code

You can't use simple math tests anymore. You can't write a test that says 2 + 2 must equal 4. Instead, you have to write tests that check if the answer "looks reasonable." Dealing with these gray areas is the hardest part of building with AI today.

Conclusion

The hardest part of building an AI company isn't writing a clever prompt or picking the best model.

The real challenge is building a stable system that doesn't crash when the AI gets slow, expensive, or weird. The future belongs to engineers who can build reliable apps using unpredictable tools.

Prerequisites

Before we dive into the code, here’s what you should already know:

• Node.js

• Express.js

• MongoDB

If you’re not familiar with any of these, just make sure they’re installed on your machine and you're ready to go.

Step 1: Set Up the Project

Let’s start by creating a new directory for the project and initializing a Node.js application.

1. Create a directory for the project:

    mkdir graphql-node-express-mongo
   

2. Navigate into the directory:

    cd graphql-node-express-mongo
   

3. Initialize the npm project:

    npm init -y
   

Now we’ll install the dependencies to set up the Express server, connect to MongoDB, and provide GraphQL capabilities:

npm install express express-graphql graphql mongoose dotenv

• express: Web framework for Node.js.

• express-graphql: Middleware to integrate GraphQL with Express.

• graphql: The core GraphQL library.

• mongoose: ODM (Object Data Modeling) library for MongoDB.

• dotenv: Helps load environment variables from a .env file.

Step 2: Setting Up MongoDB

If you don’t have MongoDB set up yet, here’s what to do:

• For local MongoDB, install it and start the MongoDB server.

• For MongoDB Atlas (cloud), create a free cluster and grab your connection string.

Once you have the connection string, create a .env file in the root folder and add the MongoDB URI:

# .env
MONGO_DB_URI = "<Your MongoDB Connection String>"

This will ensure your MongoDB credentials are kept secure.

Step 3: Create the GraphQL Schema

Next, we’ll define the GraphQL schema. Create a new file called schema.js in the root of your project.

Define the MongoDB Schema

Let’s start with a simple User model for MongoDB.

// models/User.js
const mongoose = require('mongoose');

const userSchema = new mongoose.Schema({
  name: String,
  email: String,
});

const User = mongoose.model('User', userSchema);

module.exports = User;

Define the GraphQL Schema

Now, let’s create the GraphQL schema, including queries and mutations.

// schema.js
const { GraphQLObjectType, GraphQLSchema, GraphQLString, GraphQLList } = require('graphql');
const User = require('./models/User');

// Define the GraphQL User Type
const UserType = new GraphQLObjectType({
  name: 'User',
  fields: () => ({
    id: { type: GraphQLString },
    name: { type: GraphQLString },
    email: { type: GraphQLString },
  }),
});

// Root Query to fetch users
const RootQuery = new GraphQLObjectType({
  name: 'RootQueryType',
  fields: {
    users: {
      type: new GraphQLList(UserType),
      resolve(parent, args) {
        return User.find(); // Fetch all users from MongoDB
      },
    },
    user: {
      type: UserType,
      args: { id: { type: GraphQLString } },
      resolve(parent, args) {
        return User.findById(args.id); // Fetch a user by ID
      },
    },
  },
});

// Mutation to add a new user
const Mutation = new GraphQLObjectType({
  name: 'Mutation',
  fields: {
    addUser: {
      type: UserType,
      args: {
        name: { type: GraphQLString },
        email: { type: GraphQLString },
      },
      resolve(parent, args) {
        const user = new User({
          name: args.name,
          email: args.email,
        });
        return user.save(); // Save the new user to MongoDB
      },
    },
  },
});

// Create the GraphQL Schema
const schema = new GraphQLSchema({
  query: RootQuery,
  mutation: Mutation,
});

module.exports = schema;

Step 4: Set Up the Express Server

Now, let’s wire everything up by setting up the Express server and GraphQL middleware. Create a file called server.js in your project’s root folder.

// server.js
const express = require('express');
const mongoose = require('mongoose');
const { graphqlHTTP } = require('express-graphql');
const dotenv = require('dotenv');
const schema = require('./schema');

// Load environment variables from the .env file
dotenv.config();

const app = express();

// Connect to MongoDB
mongoose.connect(process.env.MONGO_DB_URI, {
  useNewUrlParser: true,
  useUnifiedTopology: true,
})
  .then(() => console.log('MongoDB connected'))
  .catch(err => console.log(err));

// Set up the GraphQL endpoint
app.use('/graphql', graphqlHTTP({
  schema,
  graphiql: true, // Enable GraphiQL for testing queries
}));

// Start the server
app.listen(4000, () => {
  console.log('Server running on http://localhost:4000/graphql');
});

Step 5: Testing the GraphQL API

Once your server is running, open http://localhost:4000/graphql in your browser. You should see GraphiQL, a web-based IDE for testing GraphQL queries.

Test Query: Fetch All Users

To fetch all users, enter this query in the GraphiQL interface:

{
  users {
    name
    email
  }
}

Test Mutation: Add a New User

To add a new user, run this mutation:

mutation {
  addUser(name: "Jane Doe", email: "jane.doe@example.com") {
    name
    email
  }
}

You should see the newly added user in the response.

Step 6: Conclusion

Congratulations! You’ve successfully built a GraphQL API with Node.js, Express.js, and MongoDB. In this tutorial, you’ve learned how to:

• Set up a MongoDB connection.

• Create GraphQL queries and mutations.

• Set up an Express server to serve your GraphQL API.

This is just the beginning. You can now expand your API by adding authentication, pagination, or more complex queries and mutations.

Next Steps:

• Implement authentication (e.g., using JWT tokens).

• Add pagination for handling large data sets.

• Deploy your application to services like Vercel or AWS for production.

Common Issue: 404 Errors on Deployment

Sometimes, even after deploying your app on Vercel, you may still encounter a 404 error. This could happen due to several reasons such as incorrect configurations, API routes not being recognized, or module alias issues. Let’s walk through how to avoid these issues and deploy your app smoothly.

Step 1: Initialize a TypeScript Express.js Project

First, you need to initialize your TypeScript Express.js project.

1. Initialize the project:

    npm init -y
   

2. Install dependencies for TypeScript and Express:

    npm install express
    npm install typescript @types/node @types/express --save-dev
   

3. Set up tsconfig.json:
   This file will configure how TypeScript compiles your project.

   Create a tsconfig.json file:

    {
      "compilerOptions": {
        "target": "ES2020",
        "module": "commonjs",
        "esModuleInterop": true,
        "allowSyntheticDefaultImports": true,
        "noImplicitAny": true,
        "moduleResolution": "node",
        "sourceMap": true,
        "outDir": "dist",
        "baseUrl": ".",
        "paths": {
          "*": [
            "node_modules/*",
            "src/types/*"
          ]
        }
      }
    }
   

4. Add mandatory scripts in package.json: In your package.json, you’ll need to add the following scripts:

    {
      "scripts": {
        "start": "node dist/server.js",
        "build": "tsc",
        "dev": "nodemon src/server.ts"
      }
    }
   

Step 2: Set Up the Vercel Configuration

Now, let's configure the Vercel deployment.

1. Create a vercel.json file:
   This configuration file tells Vercel how to build and route your app. Here's an example configuration:

    {
      "version": 2,
      "builds": [
        {
          "src": "dist/server.js",
          "use": "@vercel/node"
        }
      ],
      "routes": [
        {
          "src": "/(.*)",
          "dest": "dist/server.js"
        }
      ],
      "buildCommand": "npm run build",
      "outputDirectory": "dist"
    }
   

   Explanation:

   • builds: Defines the build process and points to the dist/server.js file.

   • routes: Routes incoming requests to dist/server.js.

   • buildCommand: The command that Vercel uses to build the app (npm run build).

   • outputDirectory: Specifies that Vercel should look in the dist directory for the final build output.

Step 3: Handle Module Aliases

//package.json
{
    ...,
    "_moduleAliases": {
        "@": "dist"
    },
    ...
}

If you're using module aliases, especially with paths like "@": "dist", Vercel may not recognize them during the build process. To resolve this:

1. Install tsc-alias: This tool helps decouple the aliases during the build process.

    npm install tsc-alias --save-dev
   

2. Update the build script in package.json to use tsc-alias:

    {
      "scripts": {
        "build": "tsc && tsc-alias"
      }
    }
   

   This ensures that after TypeScript compiles your project, tsc-alias will replace any aliases with the correct paths.

Step 4: Deploying to Vercel

Once your project is set up, it's time to deploy it to Vercel.

1. Push your code to GitHub:
   Make sure your project is pushed to a GitHub repository.

2. Link your GitHub project with Vercel:

   • Go to the Vercel dashboard.

   • Click on “New Project” and import your GitHub repository.

   • Set “Framework Preset” to “Other”.

3. Deployment:

   • After linking your project, Vercel will begin the build process and deploy the app.

   • If everything is configured correctly, you should be able to access your app at the provided Vercel URL.

Step 5: Troubleshooting 404 Errors

Sometimes, you may still encounter 404 errors after deployment. Here are a few things to check:

1. Incorrect File Paths:
   Ensure that the file paths are correctly specified in your vercel.json file, especially the entry point (dist/server.js).

2. Missing API Endpoints:
   Verify that all your API routes are properly defined and exported from your server.ts file.

3. Serverless Function Issues:
   Vercel treats each API endpoint as a serverless function. Ensure that the structure of your app matches the expected serverless function format (i.e., files in the /api directory).

4. TypeScript Build Errors:
   If you made any changes to the TypeScript configuration, run npm run build locally to check for any errors before deploying.

Conclusion

Deploying a TypeScript Express.js app on Vercel can be a smooth experience once you understand the configuration and handling of module aliases. In this article, we covered the essential steps to set up your TypeScript Express.js app, handle build issues, and deploy it to Vercel while fixing common 404 errors. By following this guide, you should be able to deploy your app seamlessly to Vercel and ensure that it works as expected.

Happy deploying!

What is Tokenization?

In the context of design systems, tokenization refers to the practice of converting design properties (such as colors, typography, spacing, etc.) into reusable, consistent values called tokens. These tokens act as the building blocks of the design system, providing a way to maintain visual consistency across an application, even as it grows in size and complexity.

Design tokens are typically abstracted into a centralized file or configuration and can represent:

• Colors (primary, secondary, background, etc.)

• Typography (font sizes, line heights, font families)

• Spacing (margins, paddings, etc.)

• Borders, Shadows, and Other UI Elements

Tokens allow design teams to maintain a single source of truth for the design elements, making the application easier to scale and maintain over time.

Examples of Famous Apps That Use Tokenization

Many large-scale applications have adopted tokenization to build consistent, scalable design systems. Here are some examples of famous companies using tokenization:

• Spotify: The music streaming giant uses design tokens in its design system to ensure consistency in UI elements such as buttons, typography, and branding, making their design adaptable across devices.

• Shopify: Shopify’s Polaris design system leverages tokenization to maintain consistent visual styles, allowing developers and designers to work together efficiently.

• IBM's Carbon Design System: IBM uses tokens to define key design properties across their applications, ensuring uniformity in user experience across various platforms.

• Salesforce Lightning: Salesforce’s design system uses tokens to maintain visual consistency in its cloud services, providing a solid foundation for rapid feature development.

Why Tokenization Matters

Tokenization plays a vital role in maintaining consistency, speeding up development, and enhancing collaboration across teams. Here are several reasons why tokenization is important:

1. Consistency Across Platforms

Tokens ensure that the same design properties (e.g., colors, typography) are used consistently across multiple platforms and devices. This makes it easier to deliver a cohesive user experience regardless of the environment.

2. Faster Iterations

When design tokens are centralized, making changes becomes much faster. For instance, changing the color of a primary button or adjusting spacing can be done by simply modifying a value in the token file, and it will automatically propagate throughout the app.

3. Improved Collaboration

Designers and developers can work more seamlessly with a shared understanding of design tokens. This reduces the chances of inconsistencies and errors in the implementation of visual elements, enhancing teamwork and communication.

4. Scalability

As applications grow, maintaining visual consistency can become a complex task. Tokenization makes it easier to scale design systems by ensuring that design updates can be applied globally without affecting individual components or layouts.

5. Maintainability

By keeping all design-related properties in one centralized location, tokenization makes it easier to maintain and update the design system, especially as the product evolves or new features are added.

Implementing Tokenization in React.js

Implementing tokenization in a React.js project involves defining your design tokens and then using them within your React components. Here's a step-by-step guide to getting started:

Step 1: Set Up the React Project

Begin by setting up a React.js project using TypeScript for better type safety and maintainability. You can easily create a new project using Create React App or Vite.

npx create-react-app my-app --template typescript

Step 2: Define Design Tokens

Design tokens are typically stored in a JavaScript or TypeScript object, or in a JSON file. Here’s an example of a theme file with defined tokens for colors, spacing, and typography:

// src/theme.ts
const theme = {
  colors: {
    primary: "#6200ee",
    secondary: "#03dac6",
    background: "#ffffff",
  },
  spacing: {
    small: "8px",
    medium: "16px",
    large: "24px",
  },
  typography: {
    fontSize: "16px",
    fontFamily: "'Roboto', sans-serif",
  },
};

export default theme;

Step 3: Use Tokens in Components

Now that you have defined the tokens, you can use them within styled components. Here's an example of a Button component that uses the tokens for styling:

// src/components/Button.tsx
import React from 'react';
import styled from 'styled-components';
import theme from '../theme';

const Button = styled.button`
  background-color: ${theme.colors.primary};
  padding: ${theme.spacing.medium};
  color: #fff;
  font-size: ${theme.typography.fontSize};
  border: none;
  border-radius: 4px;
  cursor: pointer;
`;

const ButtonComponent: React.FC = () => {
  return <Button>Click Me</Button>;
};

export default ButtonComponent;

Step 4: Dynamic Theming (Light/Dark Mode)

To support multiple themes (e.g., light and dark mode), you can use React Context or CSS variables. Below is an example of how you might toggle themes using React Context:

// src/context/ThemeContext.tsx
import React, { createContext, useState, ReactNode } from 'react';

type Theme = 'light' | 'dark';

interface ThemeContextType {
  theme: Theme;
  toggleTheme: () => void;
}

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

const ThemeProvider: React.FC<{ children: ReactNode }> = ({ children }) => {
  const [theme, setTheme] = useState<Theme>('light');

  const toggleTheme = () => {
    setTheme((prevTheme) => (prevTheme === 'light' ? 'dark' : 'light'));
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

export { ThemeProvider, ThemeContext };

Best Practices for Tokenization in React.js

To ensure your tokenization strategy is effective, follow these best practices:

• Clear and Consistent Naming: Use clear and descriptive names for your tokens. For example, use primary-color rather than color1 for better clarity and understanding.

• Modularize Tokens: Organize your tokens into logical groups (e.g., colors, typography, spacing) to keep them modular and maintainable. This allows for easier updates and scaling.

• Use Tools for Token Management: Tools like Style Dictionary and Theo can help automate the process of generating and managing design tokens.

• Document Tokens: Proper documentation is crucial. Keep a reference guide to help developers and designers understand how to use the tokens in their workflow.

• Ensure Accessibility: When defining colors, check for accessibility standards like sufficient contrast between text and background colors.

Conclusion

Tokenization is a powerful technique for creating scalable, maintainable, and consistent design systems. By abstracting design properties into reusable tokens, you can improve the development process, enhance collaboration, and make it easier to scale your applications. When implemented in React.js, tokenization allows developers to create visually consistent user interfaces with minimal effort, enabling faster iterations and greater flexibility.

Call to Action

Want to implement tokenization in your next project? Let’s connect! Whether you're starting from scratch or looking to integrate tokenization into an existing React.js project, I can help you build a scalable design system that suits your needs.

What is Image Classification?

Image classification is the process of teaching a computer to recognize and categorize objects within an image. For example, a computer can learn to distinguish between pictures of cats, dogs, and birds. This ability to categorize images helps in automating tasks that involve visual data.

How Does Image Classification Work?

1. Collecting Data: The first step in image classification is gathering a large set of images. These images must be labeled correctly to teach the computer what each image represents.

   

2. Training the Model: Using a special kind of AI model called a neural network, the computer learns from the labeled images. During training, the model examines each image and tries to understand the features that define each category.

   

3. Testing the Model: After training, the model is tested with new images it hasn't seen before. This helps to check if the model can accurately classify these new images.

   

4. Making Predictions: Once the model is trained and tested, it can be used to make predictions on new images. For example, you can show it a picture of a cat, and it will tell you if the image contains a cat or not.

   

Applications of Image Classification

Image classification has many practical uses in our daily lives. Some of the common applications include:

• Healthcare: Identifying diseases from medical images.

• Security: Recognizing faces for security purposes.

• Retail: Sorting and organizing products in stores.

• Social Media: Tagging people in photos automatically.

Why is Image Classification Important?

Image classification helps in many ways, making processes faster and more efficient. It reduces the need for manual work and allows computers to handle large amounts of visual data quickly. This technology is advancing rapidly and continues to make significant impacts in various fields.

Conclusion

Image classification is a powerful tool in AI that enables computers to recognize and categorize images. By understanding how it works and its applications, we can appreciate how it contributes to various aspects of our lives. As technology continues to evolve, image classification will play an even greater role in shaping our world.

Understanding Scalable Data Storage

Scalable data storage solutions are designed to handle increasing amounts of data efficiently. They ensure that as your data grows, the system can scale without compromising performance or reliability. Scalability can be achieved through various methods, including horizontal scaling (adding more machines) and vertical scaling (upgrading existing machines).

Types of Databases

1. Rlational Databases (RDBMS)

Relational databases, such as MySQL, PostgreSQL, and Microsoft SQL Server, are known for their structured data storage using tables with defined relationships. They are ideal for applications requiring complex queries, transactions, and data integrity.

Pros:

• Strong consistency and reliability.

• Support for complex queries and transactions.

• Mature technology with extensive community and support.

Cons:

• Scaling vertically can be expensive.

• Less flexible for handling unstructured data.

2. NoSQL Databases

NoSQL databases like MongoDB, Cassandra, and Couchbase are designed to handle unstructured or semi-structured data. They offer flexibility in data modeling and are optimized for high performance and scalability.

Pros:

• Horizontal scaling capabilities.

• Flexibility in data modeling.

• Better suited for large-scale, distributed systems.

Cons:

• May lack strong consistency models.

• Limited support for complex queries and transactions.

3. NewSQL Databases

NewSQL databases, such as Google Spanner and CockroachDB, combine the best features of traditional RDBMS and NoSQL databases. They provide scalability and performance while maintaining SQL compatibility.

Pros:

• High scalability with SQL-like query capabilities.

• Strong consistency and support for ACID transactions.

• Good for applications requiring both scalability and transactional integrity.

Cons:

• Emerging technology with varying maturity levels.

• Can be complex to set up and manage.

Choosing the Right Database

Selecting the appropriate database for your application depends on various factors, including the nature of your data, performance requirements, and scalability needs.

1. Data Structure

   • Structured Data: If your application primarily deals with structured data and requires complex queries and transactions, a relational database might be the best choice.

   • Unstructured Data: For applications handling large volumes of unstructured or semi-structured data, NoSQL databases offer the flexibility and scalability needed.

2. Scalability Requirements

   • Horizontal Scalability: If you anticipate significant growth and need to scale out across multiple servers, consider NoSQL databases or NewSQL solutions.

   • Vertical Scalability: For applications that can benefit from upgrading existing hardware, traditional RDBMS might suffice.

3. Consistency vs. Availability

   • Strong Consistency: If your application requires strong consistency and ACID transactions, RDBMS and some NewSQL databases are suitable.

   • Availability and Partition Tolerance: If your application prioritizes availability and can tolerate eventual consistency, NoSQL databases might be more appropriate.

4. Performance Needs

   • High Throughput and Low Latency: For applications requiring high performance and low latency, NoSQL databases or NewSQL solutions can provide the necessary speed and efficiency.

5. Cost Considerations

   • Infrastructure Costs: Consider the costs of scaling your infrastructure, whether vertically or horizontally, and choose a database that aligns with your budget and scaling strategy.

Conclusion

Choosing the right database for your data-centric application is a critical decision that impacts performance, scalability, and overall success. By understanding the strengths and limitations of different types of databases, you can make an informed choice that aligns with your application's specific needs. Whether you opt for a traditional RDBMS, a flexible NoSQL database, or a modern NewSQL solution, the key is to ensure that your database choice supports your application's growth and performance requirements effectively.

In this article, we’ll cover the top AI trends to watch in 2024. Don’t worry—these trends are easy to understand, and they’re for anyone interested in how AI is changing technology and how you can start exploring it.

Generative AI: Creativity at Your Fingertips

Imagine being able to create content—like images, music, or even code—just by typing a few words. That's the power of Generative AI, and it's one of the hottest trends right now. Tools like OpenAI's ChatGPT and DALL·E are leading the charge, making it easier than ever to generate creative outputs.

Note: DALL-E is not allowing new users but if you want to use this feature, you can switch to a ChatGPT Plus account.

Why You Should Care:
Generative AI is perfect for automating creative tasks. If you’re a developer who loves tinkering with code but isn't much of an artist, generative AI can help you create stunning visuals or even write content for you.

How to Get Started:
Check out platforms like OpenAI's Playground, where you can experiment with generating text and images with minimal setup. It's super beginner-friendly!

2. AI-Powered Automation: More Time to Code

Automation isn’t new, but AI is taking it to the next level. Think beyond basic scripts—AI can now handle complex tasks like data analysis, customer service, and even software testing.

Why You Should Care:
As developers, we’re always looking for ways to save time. AI-powered automation lets you focus on the fun stuff (like coding new features) while the AI handles the repetitive tasks.

How to Get Started:
Look into tools like Zapier or UiPath, which offer AI-driven automation that’s easy to set up, even if you don’t have a lot of experience with AI.

3. AI in Healthcare: Code That Saves Lives

AI is making waves in healthcare, and it’s not just hype. From diagnosing diseases to personalizing treatments, AI is revolutionizing the way we approach medicine.

Why You Should Care:
Healthcare is one of the most impactful areas where AI can make a difference. If you're looking to work on projects that have a real-world impact, healthcare AI is a field to watch.

How to Get Started:
Explore datasets like those from Kaggle’s healthcare competitions. They’re a great way to practice building AI models that solve real-world problems.

4. AI-Powered Personalization: Making Users Happy

Ever wonder how Netflix knows exactly what you want to watch next? That’s AI-powered personalization in action. In 2024, this trend is only going to get bigger, as companies use AI to tailor experiences to individual users.

Why You Should Care:
Personalization can drastically improve user experience, which is key to keeping users engaged with your apps or websites.

How to Get Started:
Try out recommendation engine APIs like those from Amazon or Google. They’re easy to integrate into your projects and can give you a feel for how AI-powered personalization works.

5. AI for Everyone: The Rise of No-Code AI

Finally, let’s talk about accessibility. AI is becoming more user-friendly, thanks to no-code and low-code platforms. These tools allow you to build AI models without needing deep programming skills.

Why You Should Care:
No-code AI platforms democratize AI, making it accessible to everyone. If you're just starting out, these tools are a fantastic way to begin your AI journey without getting bogged down in the technical details.

How to Get Started:
Platforms like Teachable Machine and RunwayML let you create AI models with simple drag-and-drop interfaces. Give them a try to see how easy AI can be!

Conclusion

And there you have it—some of the top AI trends to keep an eye on in 2024. Whether you're interested in automation, ethical AI, or just want to start experimenting with no-code platforms, there's something here for everyone. The world of AI is expanding fast, and now’s the perfect time to get involved.

So, what are you waiting for? Dive in and start exploring these trends. Who knows, maybe your next project will be powered by AI!

Why learn with AI?

AI has become an essential tool in today's world. Before the arrival of AI tools like ChatGPT and Gemini, the learning curve for developers involved learning new concepts, encountering problems, and searching for solutions on Google or StackOverflow. However, with the arrival of AI tools, this learning curve has transformed. Developers now prefer to type their problems into ChatGPT and receive code solutions directly. But here's a question, Is this a threat to developers that AI can code and replace developers?

As someone beautifully said:

"AI cannot replace labors and human-work completely, but people using AI can perform better at their jobs and work."

It's now up to you whether you want to embrace this trend and learn with AI or just sit back and believe that AI can do everything. Even though AI has improved significantly over the years, you still need to provide it with instructions to perform specific tasks.

ChatGPT: A Powerful Learning Tool

Since most programming languages share common attributes, with differences primarily in syntax and folder structure for libraries and frameworks, learning them becomes easier. You can use ChatGPT to get help with various topics - whether you need a course outline for React.js, have a code problem that needs solving, or are looking for ideas. ChatGPT is a valuable tool for assistance and guidance.

Learning React with ChatGPT

Learning React is not straightforward where you master it in one hour and then immediately build a top-notch website. You'll need to start with the basics first.

Pre-requisites:

• HTML

• CSS

• JavaScript

You must have foundational knowledge of HTML, CSS, and Javascript before you learn React.js.

Starting with Course Outline

Getting a course outline is the crucial step before you start learning anything or even before reading a book. We can generate an outline using ChaGPT but I won't recommend it if you're an absolute beginner, you will be lost with a lot of topics that might not be important at the moment. However, you can learn the following topics one by one and practice them on CodeSandbox, which we will learn later about CodeSandbox:

• Creating a Project with CodeSandbox

• JSX, JSX vs HTML

• Components and Types

  • Functional Components

  • Class Components (Just Overview)

• Props

• States

• Event Handling

• Conditional Rendering

• Rendering Lists

• Component Life Cycle Methods

• Hooks - Introduction to hooks

  • useState

  • useEffect

  • useRef

• Styling in React

  • Inline Styling

  • Using CSS Classes

Alternatively, if you want to create your own outline using ChatGPT, type the following prompt:

"I want to learn React.js. Generate me an outline to learn it step by step."

ChaGPT will generate an outline for you. The response can be varied based on your prompt.

For our prompt, the outline begins with "Fundamentals of JavaScript ES6". If you do not have foundational knowledge in JavaScript, HTML, and CSS, make sure to learn those first before diving into React.

In the second part, the outline starts with React. It recommends starting with the basics of React and then learning topics such as React components, event handling, conditional rendering, and more.

The outline generated by ChatGPT is wonderful. However, we want to learn fast by eliminating the non-mandatory topics, for now, we we can follow my suggested list.

Creating React.js App with CodeSandbox

CodeSandbox is an excellent tool for developing applications in the cloud. It removes the need to set up a local environment, enabling you to code, run, and develop your apps entirely online.

Visit https://codesandbox.io/ and sign in. If you haven't registered yet, you'll need to create an account first.

Once your account is ready, select Sandbox from the top bar.

You will see a list of templates to choose from. Select the first one labeled "React."

Once you've selected the template, you'll be prompted to enter configurations, such as the Sandbox Name. Click the "Create Sandbox" button to proceed.

It will set up the project for you.

• Explorer: It shows all the files and available folders. Initially it will you the default project files and folders.

• Content Editor: Whichever file you select to edit, will show in the content editor section.

• Live Preview: Whatever changes you make, it will show you in real time.

The entry file for the project will be index.js. However, you the entry

Learning the topics: Use ChatGPT

JSX and JSX vs HTML

As the first React.js - related topic in our list is "JSX and JSX vs HTML", let's type the following prompt on ChatGPT and learn it:

"What's JSX? What's the difference between HTML and JSX?"

ChatGPT can provide quick insights on the topic you're learning about. If you find the answer is not relevant, you can re-generate the response or adjust your prompt to request a more concise answer.

For the answer, ChatGPT also provides examples to demonstrate the differences between HTML and JSX. In case it does not provide any example, you can type a prompt to request an example as well.

The next topic in the list is components.

Component

Let's type the following prompt to ask ChatGPT to answer it:

"What are components in React.js? Discuss its types. Give examples."

Similarly, you can search for other topics while practicing on CodeSandbox. If you find that you do not understand a topic, you can always adjust your prompt to get a concise, clearer, and more relevant answer.

Conclusion

In today’s rapidly evolving world of AI, the learning curve for developers has changed significantly. To take full advantage of these advancements, it's crucial to learn how to work with popular AI tools like ChatGPT to enhance your learning experience.

What is Git?

Git is a distributed version control system designed to track changes in source code during software development. It allows multiple developers to collaborate on projects, keeping track of changes, and managing different versions of code.

Key Concepts in Git:

Before diving into Git commands, it's essential to understand some key concepts:

1. Repository (Repo): A repository is a collection of files and folders, along with their revision history. It's the central storage location for a project.

2. Commit: A commit is a snapshot of changes made to files in a repository. It represents a specific version of the project at a given point in time.

3. Branch: A branch is a parallel version of the codebase, allowing developers to work on features or fixes independently without affecting the main codebase.

4. Pull Request (PR): A pull request is a proposed change submitted by a developer to merge their code changes into the main branch of a repository.

Basic Git Commands:

# Initialize a new Git repository
git init

# Clone a remote repository to your local machine
git clone [repository_url]

# Add changes to the staging area before committing
git add [file_name]

# Commit changes with a descriptive message
git commit -m "commit_message"

# Push committed changes to a remote repository
git push

# Fetch changes from a remote repository and merge them into the current branch
git pull

# List all branches in the repository
git branch

# Switch to a different branch
git checkout [branch_name]

# Merge changes from one branch into another
git merge [branch_name]

GitHub Usage:

GitHub is a web-based platform built on top of Git, providing additional features for collaboration and project management.

1. Create a Repository: Click on the "New" button to create a new repository on GitHub. Give it a name, description, and choose visibility settings.

2. Clone Repository: Use the "Clone or download" button to copy the repository URL. Then, use the git clone command to clone the repository to your local machine.

3. Branches and Pull Requests: Create branches for new features or fixes using the branch button. After making changes, create a pull request to propose merging your changes into the main branch.

4. Collaborate: GitHub allows multiple developers to collaborate on a project by forking repositories, creating issues, and reviewing pull requests.

5. Explore Projects: Explore trending repositories, contribute to open-source projects, or showcase your work by creating your profile and repositories.

Conclusion:

Git and GitHub are powerful tools for version control and collaboration in software development. By understanding basic Git commands and GitHub usage, developers can effectively manage their projects, collaborate with teams, and contribute to open-source communities. Start by practicing the commands mentioned above and exploring GitHub's features to become proficient in using these essential tools.

Understanding JavaScript Arrays

At its core, an array is a data structure that allows you to store multiple values within a single variable. In JavaScript, arrays can hold various data types, making them incredibly flexible.

Creating Arrays

Before we dive into array methods, let's explore how to create arrays in JavaScript:

// Creating an array of numbers
let numbers = [1, 2, 3, 4, 5];

// Creating an array of strings
let fruits = ['apple', 'orange', 'banana'];

// Creating a mixed-type array
let mixedArray = [1, 'hello', true, null];

Essential JavaScript Array Methods

1. push() and pop()

The push() method adds one or more elements to the end of an array, while pop() removes the last element from the array.

let colors = ['red', 'green', 'blue'];
colors.push('yellow'); // Adds 'yellow' to the end
let removedColor = colors.pop(); // Removes and returns 'blue'

2. shift() and unshift()

shift() removes the first element from an array, and unshift() adds one or more elements to the beginning.

let cities = ['New York', 'Paris', 'Tokyo'];
cities.shift(); // Removes 'New York'
cities.unshift('London'); // Adds 'London' to the beginning

3. slice()

The slice() method extracts a portion of an array and returns a new array without modifying the original.

let numbers = [1, 2, 3, 4, 5];
let slicedNumbers = numbers.slice(1, 4); // Returns [2, 3, 4]

4. splice()

splice() is used to add or remove elements from a specific index in an array.

let fruits = ['apple', 'orange', 'banana'];
fruits.splice(1, 1, 'grape', 'kiwi'); // Removes 'orange' and adds 'grape' and 'kiwi'

5. map()

The map() method creates a new array by applying a function to each element of the original array.

let numbers = [1, 2, 3, 4, 5];
let doubledNumbers = numbers.map(num => num * 2); // Returns [2, 4, 6, 8, 10]

6. filter()

filter() creates a new array with elements that pass a specific condition.

let numbers = [1, 2, 3, 4, 5];
let evenNumbers = numbers.filter(num => num % 2 === 0); // Returns [2, 4]

Conclusion

JavaScript array methods provide powerful tools for manipulating data efficiently. By mastering these methods, developers can streamline their code and enhance the functionality of their applications. Whether you're a beginner or an experienced developer, a solid understanding of JavaScript arrays and their methods is crucial for building robust and dynamic web applications.

Controlled Components:

Controlled components in React.js are those in which the state of form elements, such as input fields, checkboxes, and radio buttons, is managed and controlled by React. This is achieved by binding the value of the form elements to the state and updating that state through event handlers, typically the onChange event.

Let's take a look at an example of a controlled component:

import React, { useState } from 'react';

const ControlledComponent = () => {
  const [inputValue, setInputValue] = useState('');

  const handleChange = (event) => {
    setInputValue(event.target.value);
  };

  return (
    <input
      type="text"
      value={inputValue}
      onChange={handleChange}
    />
  );
};

In this example, the inputValue state reflects the current value of the input field, and any changes to the input are managed through the handleChange event handler.

Uncontrolled Components:

On the other hand, uncontrolled components allow form elements to maintain their own state within the DOM, without direct interference from React. The state is managed by the DOM itself, and you can access the values using refs.

Consider the following example of an uncontrolled component:

import React, { useRef } from 'react';

const UncontrolledComponent = () => {
  const inputRef = useRef();

  const handleClick = () => {
    alert(`Input Value: ${inputRef.current.value}`);
  };

  return (
    <>
      <input type="text" ref={inputRef} />
      <button onClick={handleClick}>Get Input Value</button>
    </>
  );
};

In this case, the inputRef is used to access the current value of the input field directly from the DOM.

Choosing Between Controlled and Uncontrolled Components:

The decision to use controlled or uncontrolled components depends on the specific requirements of your application.

• Controlled Components: Use them when you need centralized control over the form elements' state, such as when implementing validation or manipulating input before updating the state.

• Uncontrolled Components: Opt for uncontrolled components when integrating React with non-React code or when you prefer to let the DOM handle the form element state.

Conclusion:

Understanding the distinction between controlled and uncontrolled components in React empowers developers to make informed decisions when building forms. Whether you need fine-grained control over state or prefer a more hands-off approach, React provides the flexibility to choose the best strategy for your application's needs.

Let's talk about why it's important to create a build for your React.js application.

So, you've finished making your website with React.js, and now it's time to get it online. To do that, you'll need to host the build folder.

Here's a simple step to create build folder: Open your React.js project and just type this command:

npm run build

This command does something cool – it makes a new build folder right there in your project. Inside, you'll find all the static files and content ready to roll.

Now, let's test it out:

npm i -g serve  # Install the 'serve' package globally
npx serve build  # Run the project locally

This will let you check how your project looks and behaves in action.