DEV Community: Achal Tiwari

AI's Architecture: Infrastructure Realities Behind the Hype | Electricity or Bubble?

Achal Tiwari — Thu, 31 Jul 2025 05:04:10 +0000

The conversation around artificial intelligence often swings between two extremes: is it the new electricity, a utility that will redefine society, or the next dot-com bubble, a speculative frenzy destined for collapse? This binary view, however, misses the more crucial story. The real answer lies in the complex and fragile infrastructure upon which this revolution is being built.

To truly understand AI's trajectory, we must look past the user-facing applications and analyze its underlying systems. Are we building a robust, scalable utility grid, or are we running a collection of brilliant but brittle prototypes?

What Makes a Technology a Utility?

The "new electricity" analogy is powerful, but it demands a precise understanding of what made electricity a true utility. It wasn't just a single discovery, but the maturation of a multi-layered system:

Standardized Generation: The "war of the currents" between AC and DC was settled, leading to standardized, large-scale power generation.
Scalable Distribution: A robust, interconnected grid was built to transmit power efficiently over long distances, managing loads and ensuring consistent availability.
A Universal Interface: The simple wall socket provided a predictable, reliable interface for countless applications, abstracting away the grid's immense complexity.

Judged by these criteria, AI is not yet electricity. It lacks a standardized generation method, a truly scalable distribution network, and a universally reliable interface. Its architecture reveals a system under immense strain.

The Three Pillars of AI's Architecture: A Foundation Under Stress

The current AI boom rests on three critical—and precarious—pillars. Each carries systemic risks that are often ignored in the rush to deploy.

1. The Hardware Stack: A Geopolitical Monolith

Modern AI is, for all practical purposes, synonymous with massively parallel processing on Graphics Processing Units (GPUs). This has created a hardware stack with an unprecedented level of concentration.

The GPU Monopoly: One company, NVIDIA, holds a commanding position, accounting for an estimated 98% of the data center GPU market as of late 2023, according to Jon Peddie Research. Its CUDA software ecosystem has created a deep, defensible moat, making it difficult for competitors to gain traction.
The Fabrication Bottleneck: This dependency is magnified at the manufacturing level. NVIDIA, like most fabless chip designers, relies on TSMC in Taiwan to produce its most advanced chips. For the most advanced nodes (below 7nm), TSMC's market share consistently exceeds 90%, as reported by industry analysts like Counterpoint Research.

From a systems perspective, this is a single point of failure of global significance. The entire AI ecosystem is built on a supply chain that is geographically concentrated and geopolitically fragile. This creates supply volatility, high costs, and a platform risk that is almost impossible to mitigate—the antithesis of a resilient, decentralized infrastructure.

2. The Energy Stack: A Crisis of Scale

The computational demands of the hardware stack create a secondary crisis: energy consumption.

Unsustainable Growth: A 2023 study published in the journal Joule estimated that if the current growth trajectory continues, the AI sector alone could consume between 85 and 134 terawatt-hours (TWh) of electricity annually by 2027. To put that in perspective, that's comparable to the annual electricity consumption of entire countries like Argentina or the Netherlands.
Data Center Design Limits: AI workloads challenge traditional data center design. The power density required by racks of modern GPUs exceeds the cooling and power delivery capabilities of many existing facilities. This is driving a costly new wave of data center construction specifically for AI, further increasing the barrier to entry and the environmental footprint.

Electricity became a utility by providing energy efficiently. AI, in its current form, consumes that energy at a rate that strains the very grid it seeks to emulate.

3. The Algorithm Stack: The Brittle Logic of Static Models

Perhaps the most misunderstood aspect of the AI stack is the nature of the models themselves. LLMs are not dynamic, learning entities. They are static, compiled artifacts.

Autoregressive Error: Models like those in the GPT family are autoregressive; they predict the next word based on the sequence of words generated so far. This architecture has a critical flaw: errors compound. A small deviation early in a response can cascade into a completely fabricated output—a "hallucination." This is not a bug to be patched but a fundamental characteristic of the design.
The Certainty Problem: Automation requires deterministic behavior within known constraints. The probabilistic nature of LLMs makes them unsuited for mission-critical tasks where certainty is non-negotiable. For systems that power finance, logistics, or medicine, "mostly right" is the same as "untrustworthy."

The Flawed API: Integrating a Probabilistic System

The final challenge lies at the integration layer. The current trend is to bolt AI onto existing products, treating it as a drop-in replacement for human-curated data or deterministic search. This is a profound architectural mistake.

Google's AI Overviews are a case in point. By inserting a probabilistic, generative system into a workflow where users expect a deterministic list of links to source material, they broke the user's trust and intent. The user's query is an API call; the expected response was a set of reliable pointers, but the new system returns a sometimes-unreliable, synthesized summary with no clear provenance. This reveals a core crisis in how we design systems with AI. It is not an all-purpose tool. It is a specific type of engine with unique properties and failure modes.

Conclusion: From Prototype to Utility—The Engineering Challenge Ahead

The architecture of modern AI does not yet resemble a public utility. It looks like a brilliant, world-changing prototype: over-centralized, energy-inefficient, and built on brittle logic. But to dismiss it as a bubble is to miss the point. These are not dead ends; they are the next great engineering frontiers.

The history of technology is the history of overcoming such obstacles. The early electrical grid faced its own immense challenges: warring AC/DC standards, immense capital costs, and public fears over safety. It matured from a novelty into a utility through relentless innovation.

AI is on the same path. The challenges of today are seeding the innovations of tomorrow:

Hardware Diversification: The industry is aggressively pursuing alternatives to the current monoculture, from new chip architectures and optical computing to brain-inspired neuromorphic processors that promise orders-of-magnitude gains in efficiency.
Algorithmic Efficiency: Researchers are developing more efficient models, like Mixture-of-Experts (MoE), and new techniques to ground models in verifiable facts, directly tackling the problems of cost and hallucination.
Sustainable Infrastructure: The energy crisis is driving innovation in everything from liquid cooling in data centers to intelligent workload management, forcing a necessary reckoning with efficiency.

The transition from an experimental prototype to a foundational utility is never easy. It requires moving beyond the initial hype and engaging in the difficult, deliberate work of building robust, reliable, and sustainable systems. This is the defining engineering challenge of our time, and its solution will truly bring us into the age of AI.

Thank you for reading. My own neural network runs on caffeine. If you found this deep dive valuable, you can help power the next one here.

How One Bad Packet Can Take Down the Internet: Welcome to BGP

Achal Tiwari — Sat, 14 Jun 2025 14:59:40 +0000

When you type “google.com” and hit enter, your computer doesn’t just talk to Google. It launches a journey through a chaotic web of networks—thousands of them, run by different companies, countries, and competitors. Somehow, your data weaves through all of them and ends up exactly where it’s supposed to.

How?

The short answer is a protocol called BGP—Border Gateway Protocol. It’s the system that tells all these independent networks how to find each other. But calling BGP a “routing protocol” is like calling diplomacy just “talking.” It’s not just technical. It’s political, fragile, and surprisingly old.

Where BGP Came From (and Why That Matters)

Back in the early days of the Internet—when it was basically just a U.S. research network—routing was easy. The whole thing was small, centralized, and trusted. The protocol at the time, EGP (Exterior Gateway Protocol), assumed that one central backbone would manage traffic for everyone else. It was top-down, like a tree. That made sense when the only people online were universities and government labs.

Then the Internet exploded.

Commercial ISPs came online. So did global telecoms, universities from around the world, private networks, military infrastructure—each with their own priorities. Suddenly, that neat hierarchy collapsed. Nobody wanted to be told how to route traffic. They wanted control.

So in 1989, two engineers—Kirk Lougheed from Cisco and Yakov Rekhter from IBM—scribbled down a new idea at an IETF meeting on napkin. That sketch became BGP. Instead of assuming trust or central control, BGP let each network decide for itself what routes to share, what routes to accept, and how to reach the rest of the Internet.

In 1989, at an IETF meeting, two engineers—Kirk Lougheed (Cisco) and Yakov Rekhter (IBM)—sketched a new idea on a napkin. That sketch became BGP.

Unlike its predecessors, BGP didn’t assume central control or mutual trust. Instead, it handed autonomy to each network: decide what to share, what to accept, and how to reach the rest of the internet—on your own terms.

It wasn’t built for harmony. It was built for distrust—and that’s exactly why it worked. Below is the original BGP protocol sketched at an IETF meeting, 1989.

BGP Doesn’t Find the Best Path—It Finds an Acceptable One

Most people assume that the Internet is optimized. That your traffic always takes the shortest or fastest route. That’s not how BGP works.

Where traditional routing protocols like OSPF or RIP focus on efficiency—metrics like hop count, link speed, or latency—BGP is all about policy. ISPs and network operators use it to make routing decisions based on business deals, geopolitical constraints, or technical limitations. They might avoid a perfectly good path because it goes through a rival network. Or prefer a longer path because it’s cheaper.

This flexibility is why BGP became the backbone of the Internet. But it also means that routing decisions aren’t always rational—or even safe.

Key Insight: BGP doesn’t care about the “best” route. It cares about what networks are willing to accept.

That trade-off—flexibility over optimization—is why your traffic might go through five countries to reach a server across the street. It’s also why a mistake by one small ISP can knock YouTube offline for half the world.

How BGP Picks a Path (and Why It’s Not the One You Expect)

Let’s say your packet wants to get from Mumbai to London. There are a dozen possible routes it could take—some fast, some slow, some cheap, some political. So how does the Internet decide?

It doesn’t. BGP does.

But BGP doesn’t look for the shortest route. It doesn’t test for latency, bandwidth, or even congestion. Instead, it runs a path-selection process based on what networks want to happen. That’s because BGP isn’t just a routing protocol—it’s a policy engine disguised as infrastructure.

What BGP Really Does: Think Diplomacy, Not Math

BGP is what’s called a path-vector protocol. That means every route announcement includes a complete list of which networks (Autonomous Systems, or ASes) the traffic will pass through. This list is called the AS-PATH, and it's central to how BGP prevents routing loops and evaluates options.

Each BGP router builds a table of all the known paths to every reachable IP prefix—and then it runs a strict decision algorithm to pick just one "best" path. But “best” in BGP doesn’t mean “fastest” or “shortest.” It means most acceptable under the local network’s policies.

Here’s how the decision process works, in order:

Local Preference: Set manually by the network operator. This overrides everything. If your ISP decides traffic to Google should go through France, that’s what happens.
AS-PATH Length: Fewer AS hops are better—if Local Preference doesn’t override it.
Origin Type: Prefer routes originated via IGP (interior) over those redistributed from EGP.
MED (Multi-Exit Discriminator): If two routes come from the same neighbor, pick the one that prefers a specific link.
eBGP Over iBGP: External BGP routes are considered more trustworthy than internal ones.
Router ID: A final tie-breaker based on the unique ID of the advertising router.

At a glance, it feels like a cascade of technical preferences. But step back, and it’s clear: the entire system is rigged for policy control. The real authority sits at the top—Local Preference—a setting that network operators configure explicitly to enforce their business, legal, or geopolitical goals.

Why Local Preference Comes First (And What That Means for You)

This is where BGP reveals its real nature. Performance? Efficiency? Not the priority. Instead, the protocol empowers every AS to shape routing based on who pays whom, who trusts whom, and who can’t legally send data where.

Let’s break that down:

Peering vs. Transit: A network might route traffic through a slower peering connection to avoid paying for transit. Even if the performance is worse, the cost savings win.
Regulatory Compliance: In countries with data sovereignty laws, ISPs are required to keep domestic traffic within national borders—even if the shortest path is international. So your data might take a detour just to stay legal.
Political Tensions: Some ASes intentionally avoid routes that pass through rivals or untrusted regions. If two countries are in conflict, their ISPs might refuse to peer directly, forcing traffic onto inefficient paths.

And that’s not a bug. It’s how the protocol was designed to work. The idea was never to build a fast or elegant Internet—it was to let thousands of networks cooperate without giving up control.

The Real-World Consequence: Strange Routes, Slow Latency, and Zero Transparency

If you’ve ever wondered why your request to a nearby server takes a bizarre, international route before looping back—it’s probably BGP. The router didn’t pick the shortest option. It picked the one that matched business rules.

And there’s no easy way to tell. BGP decisions are made behind closed doors, based on settings most users never see and deals that aren’t public. So while your browser waits, your data might be visiting Frankfurt, because someone somewhere prefers it that way.

BGP’s Fatal Flaw: It Assumes Trust (And That’s a Problem)

BGP, for all its complexity, runs on a shockingly simple assumption: every network is honest. That’s it. There’s no built-in authentication, no cryptographic checks, no enforcement. If a network claims to own an IP block, BGP believes it. If it says “send traffic here,” the rest of the Internet shrugs and obeys.

This isn’t a design oversight—it’s how the protocol was built. In 1989, the architects of BGP weren’t trying to defend against adversarial states or profit-driven hijackers. They were trying to get Stanford, MIT, and the NSF backbone to talk to each other. Trust wasn’t just assumed—it was baked into the system.

That trust still runs the global internet today. And sometimes, it breaks. Badly.

The YouTube Blackhole: When a Country Took Down a Global Platform

In 2008, Pakistan’s telecom regulator ordered ISPs to block YouTube nationwide. Instead of filtering it at the DNS level or using a firewall, Pakistan Telecom took a more blunt approach: it announced a more specific BGP route to YouTube’s IP range, pointing the traffic to a null destination. A kind of digital sinkhole.

Locally, this worked. Users in Pakistan trying to access YouTube got nothing. But here’s the catch: the route didn’t stay local.

Due to a misconfiguration—or perhaps simply a failure to filter outbound announcements—the fake route propagated to Pakistan Telecom’s upstream provider. From there, it spread to the global internet.

And because BGP always prefers more specific routes (a /24 beats a /16), the forged announcement from Pakistan overrode YouTube’s legitimate one. For hours, much of the world’s YouTube traffic was rerouted into a black hole.

There was no malicious hack. No zero-day exploit. Just a misstep—and a protocol that trusted what it shouldn’t.

Why This Keeps Happening

The YouTube hijack wasn’t a one-off glitch. BGP route leaks and hijacks are frequent, often accidental, and occasionally exploited for strategic or economic gain.

Here’s why these failures are baked into the system:

No Authentication: BGP has no native way to check whether an AS actually owns or is authorized to announce a given IP prefix. It just takes the announcement at face value.
Specificity Bias: BGP always prefers the most specific prefix. That makes /24 hijacks easy and dangerous. Even if a legitimate network announces a /16, a rogue /24 will win.
Global Scope: A single bad announcement can propagate worldwide in seconds. And unless someone’s watching—and has the power to filter—it won’t stop.

A Pattern of High-Stakes Failures

Here’s how that trust model has repeatedly collapsed:

Year	Incident	What Happened
2010	China Telecom Route Leak	37,000 prefixes—including U.S. government and military traffic—were briefly routed through China due to an accidental leak.
2017	Russian ISP Hijack	A Russian provider announced routes belonging to financial services like Visa and Mastercard. Traffic detoured through Russia for over an hour.
2021	Facebook BGP Withdrawal	Facebook’s own routers mistakenly withdrew their prefixes. Without BGP routes, Facebook, WhatsApp, and Instagram effectively vanished from the internet.

Notice the variety here: not all were malicious. Some were misconfigurations. But the outcome is the same—global disruption triggered by a local decision.

Trust Without Verification Is Fragile

The internet, despite its reputation for being robust and decentralized, hinges on a protocol that has no way to verify claims. And while proposals like RPKI (Resource Public Key Infrastructure) aim to fix this, adoption remains incomplete. Many networks still run wide open—able to be spoofed, hijacked, or leaked.

So when someone asks, “How can one small ISP cause a global outage?” the real answer is: because BGP lets them.

Why BGP Is So Hard to Fix: Securing a Protocol That Assumes Trust

BGP’s security flaws aren’t news. Engineers have known for decades that any network can claim any IP prefix, and most of the internet will accept it. The real question is: why hasn’t this been fixed?

The Fixes Exist—They Just Don’t Scale

RPKI cryptographically verifies route ownership. But adoption is low (~40%) and misconfigurations can cause valid routes to be dropped. Few networks want to risk breaking reachability.
BGPsec validates every hop in the AS path using cryptographic signatures. It solves path spoofing—but is too heavy to deploy at internet scale. Routers aren’t built for it, and nobody wants the overhead.
Manual filtering (ISPs hand-picking acceptable routes) is still common. But it’s tedious, error-prone, and doesn’t scale to 70,000+ networks.

Why This Isn’t Fixed Already

BGP has no central authority. Unlike HTTPS—where browsers enforce standards—no one can compel ISPs to secure their routing. The incentives are misaligned: the benefits of securing BGP are global, but the costs are local. Most networks don’t see a direct return on securing routes for others.

Worse, new defenses carry risk. Misconfigured RPKI can cause legitimate outages. So many networks choose reliability over security. It’s a rational response to a fragile system.

Beyond Tech: BGP Is Political

Routing isn’t just technical—it’s geopolitical. Countries like China and Russia use BGP to enforce domestic control, routing traffic through national infrastructure. Meanwhile, big content providers bypass traditional ISPs using private interconnects, reshaping who controls traffic flow.

Built-In Trade-Off: Stability Over Speed

BGP is slow to converge by design. That’s what keeps the internet stable—but it also means hijacks and outages can persist for minutes or hours. It resists change for the same reason it resists collapse: conservatism is a survival strategy.

BGP’s problems aren’t a secret. They’re just embedded in the architecture, incentives, and power structures that define the internet.

Final Thoughts: The Internet Runs on Trust, Not Design

BGP wasn’t built for scale or security—it was built for trust. And that trust is wearing thin.

Its flaws are obvious: no authentication, policy over performance, and fragile convergence. But that’s also what makes it work. Not because it’s well-designed, but because every player has just enough incentive not to break it.

The next time your traffic takes a weird route, remember: it’s not a bug. It’s BGP doing what it was never meant to do—and somehow still holding the internet together.

Like this BGP deep dive? ☕ Fuel more tech rants

Warning: May induce involuntary networking lectures at family dinners.

(Peering agreement optional)

Bloom Filters: The Smartest Lie Your System Can Tell

Achal Tiwari — Fri, 13 Jun 2025 11:39:33 +0000

Ever wonder how Google avoids crawling the same page twice across billions of URLs? Or how your browser blocks phishing links instantly without downloading a blacklist the size of a dictionary? Or how spam filters flag dodgy senders before the email even loads?

Behind all these real-time decisions is one quiet principle: systems need to ask, “Have I seen this before?” But at scale, that’s not a simple yes/no question. And answering it wrong — or slowly — can cost millions.

The Real Cost of "Remembering"

At small scale, you can use a hash set or a map to keep track. These give you lightning-fast lookups. But try storing a billion SHA-256 hashes — that's 32GB of raw memory. And that’s just the hashes, not the metadata, not the index, not the structure.

Want to ship that to every mobile browser? Or store it in L1 cache on your server? Good luck.

So big systems flip the question. Instead of asking,

“Is this in the set?”,

they ask:

“Can I say for sure this is not in the set?”

This small shift leads us to a powerful, counterintuitive tool: the Bloom Filter.

Let Me Introduce You to the Maybe-Machine

Bloom Filters don’t aim for perfect accuracy. Instead, they give you a fast, memory-efficient answer:

If something isn’t in the set → they’ll say so with complete certainty.
If something might be in the set → they say “maybe.”

That tradeoff is deliberate. It's what makes Bloom Filters ridiculously cheap, fast, and useful.

Imagine a bouncer who isn’t checking names, just checking definitely not names. Anyone who fails the test gets turned away. Everyone else gets passed to a more serious security check — your database, your backend, your full set.

How They Actually Work

Let’s walk through this. Suppose you’re Instagram and want to check if a user has seen a particular reel before. Storing every reel ID per user is a memory nightmare. So instead, you use a Bloom Filter.

It’s just two things:

A bit array of size m (all zero at the start)
k independent hash functions

To insert a reel ID X:

You run X through all k hash functions:

   h₁(X) → index₁  
   h₂(X) → index₂  
   ...  
   hₖ(X) → indexₖ

Each gives you a position in the bit array, and you set those positions to 1.

To check if another reel Y has been seen:

Hash it again using the same k functions.
Check those bit positions:

If any bit is 0 → Y is definitely new.
If all bits are 1 → maybe seen, maybe not.

And that’s it. There’s no list of IDs. No map. No real identity. Just a pattern of flipped bits.

Think About It Like This

Imagine a long row of switches (bits), all off.

Each new item you insert flips a few switches to "on," chosen by hashing. When checking later, if your item’s switches are all on, it might have been there before — or maybe someone else flipped those same switches.

What Happens If Two Items Hash to the Same Positions?

Then you’ve got a collision. But that’s not a bug — that’s inevitable. You're compressing a huge space (like all URLs) into a fixed-size array. By the Pigeonhole Principle, collisions must happen.

This is where false positives come from. If item A and item B flip the same k bits, the filter can’t tell them apart anymore. Identity gets blurred. That’s the cost of compression — and it’s baked into the model.

Once a bit is shared, it’s communal. You don’t know who flipped it anymore.

But the tradeoff is worth it — you get blazing-fast queries in a tiny amount of memory.

Okay, But How Likely Are False Positives?

Let’s do some math. Say:

Bit array size m = 10,000
You insert n = 1,000 items
Use k = 7 hash functions

The formula for false positive probability is:

\left(1 - e^{-\frac{kn}{m}}\right)^k

Plugging in:

\left(1 - e^{-0.7}\right)⁷ ≈ (1–0.496)⁷ ≈ (0.5034)⁷ ≈ 0.00819

So about a 0.82% chance of false positive — using just 1.25KB of memory.

That’s insanely efficient.

Tuning Matters

Add more items → more bits flip → more false positives.
Flip too many bits → everything looks like a “maybe” → filter gets saturated.
Use too few hash functions → less precision.
Use too many → wasteful and overlapping.

There’s even an optimal value for k:

\left(1 - e^{-\frac{kn}{m}}\right)^k

Tune it based on how many items you expect to store and how much space you can spare.

A Few Sharp Edges

You can’t delete from a basic Bloom Filter. If item A and item B both flipped the same bits, and you try to “unflip” those bits after deleting A — you might accidentally delete B’s trace too.

That’s why deletion is impossible in standard Bloom Filters.

If you really need deletion, you’ll need a Counting Bloom Filter — where instead of a bit, each position stores a counter. But you lose the original simplicity and memory efficiency.

Also: Bloom Filters aren’t cryptographically secure. In adversarial settings (e.g., BitTorrent), attackers have faked presence by spoofing bit patterns — leading to denial-of-service style distractions.

So Why Did Redis Ditch Them?

Redis once had Bloom Filters in its core, but later removed them — not because they’re useless, but because they’re specialized. Instead, they moved it into a module: RedisBloom. This lets power users access not just Bloom Filters, but more advanced probabilistic structures — Cuckoo Filters, Count-Min Sketch, Top-K, etc.

It’s a reminder: Bloom Filters aren’t silver bullets. They’re sharp tools — if you know when to use them.

The Bottom Line

Bloom Filters aren't trying to be accurate — they’re trying to be fast and cheap. They let you say “no” with confidence, and “maybe” with grace. They compress identity into rough patterns. They don’t track, they approximate. And that’s exactly why they work at scale.

So next time you build something that needs to track millions of things with limited memory — ask yourself if a perfect answer is worth the price. Because sometimes, “probably” is good enough to be brilliant.

☕️ If this post helped Bloom Filters bloom in your brain — or just made you whisper “nerdy but nice” — consider buying me a coffee. Unlike a Bloom Filter, I won't forget you. Unless you hash to the same index as someone else. Then... we’ll never know 🤷‍♂️.

Understanding the Backend Behind LLMs(No Headaches Involved)

Achal Tiwari — Tue, 20 May 2025 14:37:29 +0000

After reading this blog post, any fears you have about LLMs will be put to rest. All you need is a curious mind and a bit of focus—no advanced knowledge of machine learning or AI is required! In this article, we’ll break down the concepts behind Large Language Models in a straightforward way and even explore how they are built from the ground up. Let's start.

What are LLMs

Simply put, Large Language Models—LLMs—are smart AI systems that can read, understand, and even write text like a human. They learn from vast amounts of data using a type of technology called neural networks.

The soul of LLMs are neural networks, which are computer systems inspired by the way our brains work. Think of a neural network as a series of interconnected layers, where each layer consists of small units called neurons. These neurons work together to process information.

When you input data, like text or images, each neuron takes that information, applies some importance (or weight) to it, and sends it to the next layer. As the data moves through the layers, the network learns to recognize patterns and make decisions. This whole process gets trained through a feedback loop—by showing the model correct answers and adjusting weights to reduce errors. That's gradient descent, and it's how the magic happens. In simple terms, neural networks are like a team of problem solvers that work together to understand and generate information.

Think of it like teaching a child to recognize words and sentences by showing them countless examples. Over time, the child learns to understand context, grammar, and even nuances in meaning. Similarly, LLMs become more proficient at language tasks as they are exposed to more data.

Transformers

You may have experimented with a basic AI, like a simple neural network that predicts the next letter or word. But how do we go from that to ChatGPT, or Claude, or Bard—models that can write essays, answer questions, debug your code, and sound eerily human?

The answer is: Transformers.

If a basic neural network is like a pocket calculator—taking small inputs and spitting out answers—a Transformer is like a souped-up spreadsheet loaded with advanced formulas, macros, and automation. It doesn’t just crunch numbers—it understands context, sequence, and relationships in a way no earlier model could.

Let’s explore the secret sauce that makes Transformers so powerful. And don’t worry—we’ll decode the fancy stuff and tie it all back to everyday intuition.

1. The Power of Focus: Self-Attention

Imagine you’re reading this sentence:

"The girl gave her dog a treat."

When you get to the word "her", your brain automatically links it back to "girl". You didn’t even think about it. That’s what we call contextual understanding.

Transformers try to do something very similar. They look at all the words in a sentence and decide which ones are most important to understand the current word.

Let’s say the model is trying to figure out what "her" refers to. It “pays attention” to other words in the sentence—especially "girl". Words that matter more get higher attention; others, like "a" or "the", are gently ignored.

This ability to scan the whole sentence and decide what's relevant is called self-attention—but honestly, you can just think of it as focused reading.

2. Think Fast: Parallel Processing

Remember those old AI models that read text one word at a time, like a super-slow typewriter? They were called RNNs, and while they worked, they were painfully slow and forgetful.

Transformers said, “Why read word-by-word when you can read the whole sentence at once?”

So instead of slowly crawling through text, Transformers gobble it all up at the same time—kind of like how your brain can scan a whole paragraph and get the gist instantly.

This ability to look at everything together is what makes Transformers fast, efficient, and perfect for modern hardware like GPUs. You don’t need to remember the term parallel processing—just know that it’s like reading with both eyes open instead of peeking one word at a time.

3. Speaking the Model’s Language: Tokenizers and Embeddings

Here's the catch: Transformers don’t understand text. Not even a little.

They only speak numbers. So how do we teach them words?

First, we break words into smaller parts, called tokens. These might be entire words, chunks of words, or even just letters—whatever makes the most sense.

Then, we translate each token into a list of numbers. This list represents what that token means, kind of like a unique fingerprint for the word “cat”, or “run”, or even “xyz”. These fingerprints are called embeddings.

So when you feed the model the word “apple”, what it actually sees is a row of numbers, like [0.2, -0.5, 1.3, …]. And every word or token gets its own unique row.

All this magic of converting text to numbers? That’s just turning words into something the model can understand.

4. Building the Brain: Layers on Layers

Now comes the cool part.

Once your text is turned into numbers, the Transformer starts processing it through layers—lots and lots of layers. Each layer has a job:

One layer might focus attention to understand what matters in the sentence
Another might clean up the information so it’s easier to work with (we call this normalization)
A third might add the original info back in to prevent it from being lost along the way (called residual connections)

And then it repeats.

The model keeps passing information through layer after layer, getting smarter at every step—like a person reading a sentence again and again, each time catching more nuance.

By the end of this process, the model isn’t just looking at the word “apple”—it knows whether you meant the fruit, the company, or the color of your phone.

So What’s a Transformer, Really?

Let’s put it all together, without the tech-speak:

It reads everything at once, not word by word
It focuses on the most important parts of a sentence
It understands the meaning behind words, not just the words themselves
It builds up its understanding in layers, getting better as it goes

And that’s really what makes Transformers so special.

If you ever hear someone say "self-attention" or "positional encoding" or "multi-head architecture", just remember this:

"Ah yes, that’s the simple trick the model uses to figure out what matters, where things are, and how to make sense of it all."

The Build Phase: Engineering Your Transformer

Imagine your Transformer as a chef in the kitchen. Just like your mom takes raw ingredients (like text) and skillfully transforms them into delicious meals, a Transformer processes information in clever ways to create something meaningful—whether it’s a complete sentence, a piece of code, or even a beautiful poem.
Here's what each component does in simple terms:

1. Tokenizer: Slicing Language into Bite-Sized Chunks

Before the model can "think" about a sentence, it has to break it down into parts it can understand. That’s the tokenizer’s job.
Instead of feeding it entire words or letters, we break text into subword pieces—tiny fragments like “trans,” “form,” and “ers.” Why? Because this helps the model:

Understand unknown words by their parts (like figuring out "transformer" even if it’s never seen it)
Keep its vocabulary manageable (no need to memorize every word in the English language) You give the model: > “I’m learning transformers.”

And it might break that down into:

[“I”, “’m”, “learn”, “ing”, “transform”, “ers”, “.”]

This step is just chopping your ingredients before cooking. In tech speak, we call this tokenization.

2. Embedding Layer: Turning Words Into Numbers

Now that we’ve got our token pieces, we need to turn them into something the model can actually compute: numbers.

The embedding layer assigns each token a unique fingerprint, made up of dozens (or hundreds) of numbers. These aren’t just random values—they capture subtle features like:

What a word means
How it’s used
How it relates to other words

So the word “king” and “queen” might have very similar embeddings, just slightly adjusted for gender. It's the model’s way of “understanding” meaning without using actual definitions.

In plain terms: this is how we translate human language into something math can handle.

3. Positional Encoding: Remembering Word Order

Here’s a weird thing: transformers don’t naturally know the order of your words.

If you give it “The cat sat on the mat”, it might just see a bag of words: [cat, mat, the, sat, on, the]. That’s a problem. The position of each word matters!

Positional encoding solves this by adding a little flavor to each token's embedding—like tagging it with its position in the sentence. It’s like saying:

This is the first word
This is the second
This one came last

This way, the model knows that “cat sat on mat” is different from “mat sat on cat” (which would be a very different kind of story!).

4. Multi-Head Self-Attention: Laser-Focused Thinking

This is the Transformer’s superpower. When trying to understand a word, the model doesn’t just look at it in isolation. It looks at every other word in the sentence to decide what matters most.

Say you’re processing this sentence:

“The dog barked because it was hungry.”

What does “it” refer to? The model needs to look back at “dog” and realize that’s the star of the sentence.

Self-attention is like giving the model a pair of high-powered goggles—it can zoom in on important words, even if they’re far away in the sentence.

And multi-head just means the model wears multiple goggles at once, each focusing on a different thing: subject, tone, grammar, etc.

You don’t have to memorize the term multi-head self-attention. Just think of it as the model’s way of deciding what to pay attention to when reading.

5. Feed-Forward Network: Deeper Thinking Happens Here

After attention decides what to focus on, the model runs that info through a tiny brain—a simple set of calculations that mix, transform, and refine the meaning.

This is where the model learns things like:

“cat” and “kitten” are related
“bark” can mean sound or tree (depending on context)
“run code” is very different from “go for a run”

This layer adds complexity and depth to the model’s understanding. In technical terms, we call this a feed-forward network, but you can think of it as the deeper reasoning stage.

6. Layer Normalization + Residual Connections: Keeping It All Balanced

When you’re cooking something complex, you need to stir often and taste as you go, or the flavors might get lost, or worse—burn!

That’s what these two components do:

Residual connections take the original ingredients and mix them back in, so the model doesn’t forget what it started with
Normalization makes sure the numbers don’t get too big, too small, or too weird to process

This helps the model learn better, stay stable, and not forget the big picture. You can just think of it as keeping everything balanced and smooth.

7. Decoder (For Generating Output)

Now that the model has processed your input, we want it to say something back.

This is where the decoder comes in. It takes all the model’s internal thoughts and generates the next token, one piece at a time, until it forms a full sentence.

For Example, give it the phrase:

“Once upon a”

And it might complete:

“time, there was a dragon…”

It does this by predicting the most likely next token, then the one after that, and so on.

That’s what we call language generation.

You Don’t Have to Build Everything From Scratch

The good news? You don’t need to code all these parts by hand.

Libraries like PyTorch and TensorFlow come with plug-and-play versions of each of these blocks. It's like building with LEGO instead of carving blocks from stone.

You just need to know what each piece does, how to plug them together, and how to train the whole setup.

Feeding the LLM: Data Curation

Here’s a reality check:
No matter how fancy your model is, it won’t say anything smart unless it’s seen something smart.

Think of your large language model (LLM) like a student. A very, very eager one. It doesn’t come with built-in knowledge—it learns entirely from what you show it. So if you train it on trash, it’ll spit out trash. If you train it on gold, well… then you get magic.

This makes data curation arguably the most important part of building an LLM.

What Kind of Data Does It Need?

To talk like a human, your model has to read like a human. That means it needs to devour massive amounts of written material—anything that reflects how we use language in the real world.

We’re talking:

Books – Fiction, non-fiction, classics, obscure indie novels—it’s all valuable
Wikipedia – General knowledge, well-structured
Academic Papers – For formal tone and complex ideas
Conversations – Dialogue helps the model understand how people actually talk
Code – Yes, even programming languages are part of the diet!
Articles and Blogs – Diverse opinions, tones, and writing styles

The idea is to give the model a buffet of human language so it can learn not just vocabulary, but grammar, nuance, emotion, context, and logic.

But Don’t Just Feed It Anything...

Just as you wouldn’t let a child play with a box of mismatched puzzle pieces and expect them to complete a beautiful picture, you shouldn’t provide your model with a jumble of unfiltered internet content. Just like a complete puzzle requires the right pieces to fit together, your model needs high-quality, relevant data to create coherent and meaningful outputs.

Here are the key steps for cleaning your data in concise points:

Accuracy: Verify factual correctness.
Formatting: Remove unusual symbols and typos.
Bias and Harmful Speech: Eliminate offensive or misleading content.
Deduplication: Remove duplicate entries to avoid bias.
Privacy Redaction: Exclude sensitive information like personal identifiers.

How Much Data Are We Talking?
Let’s put things into perspective.

Model Number of Parameters Training Data (Tokens)
GPT-3 175 billion ~0.5 trillion tokens
LLaMA 2 70 billion ~2 trillion tokens
Falcon 180 billion ~3.5 trillion tokens

Reminder:
1 token ≈ ¾ of a word
100,000 tokens ≈ one full novel

So GPT-3 read the equivalent of 5 million novels during training.

But don’t panic—you don’t have to start that big. You can absolutely build a smaller model with fewer parameters and a modest amount of data. Think of it like training a student for a local competition instead of the Olympics.

Start small. Learn fast. Scale wisely.

When you're gathering all this data, set aside a chunk of it for evaluation—a final exam for your model.

If you test the model on the same stuff you trained it on, it’s like checking answers by looking at the key. To really know if it's learning, you need to test it on new, unseen examples. That’s how you know it can generalize, not just memorize.

TL;DR – The Golden Rules of Data Curation

Quality > Quantity (but yes, quantity matters too)

Variety is king: include different tones, styles, domains

Clean your data like you’re prepping ingredients for a gourmet meal

Save some for testing so you can measure real progress

Start small if needed—scale when ready

And that’s how you feed your language model. It’s not glamorous work, but it’s the foundation for everything that comes next.

Training: Where the Magic Gets Expensive

So, you've built your Transformer. It's sleek, it's complex, it's hungry for knowledge. Now comes the part where it actually learns—and spoiler alert: this is where things get intense.

Training an LLM is like sending your model to school… except the classes never stop, the exams are brutal, and the tuition fees are paid in GPU hours and electricity.

Let’s break it down.

The Two-Part Learning Cycle

Training a model boils down to two big steps, repeated over and over:

1. Forward Pass – Making a Guess

The model takes in some data—say a sentence like:

“The sun rises in the...”

It then tries to guess the next word. Maybe it says:

“carrot” 🙃

Okay, not great. But that's okay—it’s still learning.

2. Backward Pass – Learning From Mistakes

Here’s where the real growth happens.
The model compares its guess ("carrot") with the correct answer ("east"), and calculates how wrong it was. This gap is called loss.
Then, it works backward through its own logic, adjusting millions (or billions) of little dials—called parameters—to make a better guess next time.

This back-and-forth continues:

Over batches (small groups of data)
Through epochs (full passes through the dataset)
And across iterations (every single training step)

It’s like the world’s most dedicated student doing flashcards at lightning speed—millions of times.

But This Isn’t Cheap

Training modern LLMs isn’t just mentally taxing for the model—it’s a resource monster. You’ll need:

High-end GPUs (preferably more than one)
Tons of memory (RAM, VRAM, and fast storage)
Patience (unless you’re burning cloud credits)

So how do people manage this at scale? Smart techniques:

Efficiency Boosters

Parallelization

Break the training task into chunks and run them on multiple GPUs at the same time. It’s like building a house with a team instead of doing it solo.

Gradient Checkpointing

Instead of remembering everything during training (which eats memory), the model saves “checkpoints” and recalculates just the necessary parts later. It’s a clever trade-off: less memory, a bit more computation.

Hyperparameter Tuning

These are the settings that guide how the model learns. Think:

Batch size – How many examples to learn from at once
Learning rate – How aggressively to update its knowledge
Dropout rate – How often to forget things to avoid overfitting

Get these settings right, and training becomes faster, cheaper, and more effective. Get them wrong, and your model might either learn nothing—or memorize your dataset like a parrot.

Don’t Stop at Training: Fine-Tune for Your Domain

Once your model speaks fluent “general English” (or whatever language you trained it on), it’s time to give it a specialty.

This is called fine-tuning, and it’s how you turn a generalist into an expert.
Let’s say you’ve trained a model to understand basic language, but you want it to:

Answer legal questions
Write SQL queries
Diagnose medical symptoms
Handle customer service chats
Generate code in a specific language You don’t need to start from scratch again. You just fine-tune it—feed it examples from your niche and let it re-learn with a focused lens.

The model already knows how to read, write, and reason. Now, you’re just teaching it what matters in your domain.

It’s like hiring a smart intern and giving them a few weeks of on-the-job training. Soon, they’re speaking your language, using your terms, and handling tasks like a pro.

TL;DR – What to Remember

Training is the phase where the model learns from scratch. It’s expensive, slow, and compute-heavy—but essential.
You repeat a forward pass (guessing) and backward pass (learning) until your model gets good.
Use smart tools like parallelization, gradient checkpointing, and hyperparameter tuning to manage costs and complexity.
Once trained, don’t stop—fine-tune your model to specialize it for your actual needs.

Absolutely! Here's a revised, polished, and human-friendly version of the Closing Thoughts, expanded to include realistic advice for those with limited resources. It gives an honest perspective while keeping the spirit of encouragement alive—plus it includes a practical “minimum setup” for getting started with smaller models like minGPT.

Closing Thoughts

Building a Large Language Model (LLM) from scratch is a bold move.

It’s like building a car engine from raw metal. You don’t need to do it—plenty of great engines already exist—but if you do, you’ll know exactly how it works, piece by piece. And that kind of knowledge? It’s powerful.

Whether you're:

A student learning AI by doing (and not just watching tutorials)
A startup looking to build a private, domain-specific model
Or just a curious mind who loves digging deep into how things tick

...building your own LLM is more possible now than ever before.

Excited to dive in?

If you're aiming to build even a basic LLM from scratch, here’s your “starter pack”:

Core Skills

Python: The language of choice for almost all ML projects
NumPy: For working with arrays and matrices
PyTorch or TensorFlow: To build and train neural networks
Basic understanding of:
- Vectors, matrices, gradients (middle school math + intuition!)
- How neural networks work

Tools & Resources

A tokenizer (like Byte-Pair Encoding or SentencePiece)
A small, clean dataset (you don’t need 2 trillion tokens to start)
Basic compute: access to a single GPU (NVIDIA GTX 1660+, or any cloud GPU like Google Colab or Lambda Labs)

Mindset

Patience: Training even small models takes time.
Curiosity: You’ll hit confusing bugs—embrace them as learning moments.
Persistence: You will want to give up. Don’t.

Looking to Keep Costs Low?

You don’t need a supercomputer to start your LLM journey.

Many beginners use tiny transformer models to learn the fundamentals—models you can train on a laptop or free-tier cloud GPU.

Here’s a great starting point:

🔹 `minGPT` by Andrej Karpathy

A minimal, educational reimplementation of GPT
Written in clean, simple PyTorch
You can train it on tiny datasets like Shakespeare or Python code snippets
Can run on a single GPU with 4–8 GB VRAM
Helps you understand tokenization, attention, embeddings, loss functions, and training loops—without the complexity of billion-scale models

Recommended system for minGPT:

CPU: Any modern multi-core CPU (i5/i7 or Ryzen 5/7)
RAM: At least 8–16 GB
GPU: GTX 1660 Ti, RTX 3060, or better — OR Google Colab with a free Tesla T4 (or paid tier for faster A100/V100)

Other starter models to explore:

nanoGPT – Modern rewrite of minGPT with PyTorch Lightning and better training loops
TinyStories – Small LLMs trained on child-friendly stories, designed to run on a single GPU
distilGPT or GPT-Neo Mini – Pretrained small models you can fine-tune cheaply

So... Is It Worth It?

If you're after raw performance or commercial-scale apps, you're probably better off fine-tuning an existing model.

But if your goal is understanding, learning, privacy, or customization, then yes—it's absolutely worth it.

You'll not only gain insights into one of the most transformative technologies of our time, but you’ll also empower yourself to innovate, adapt, and even challenge what’s already out there.

Final Thoughts

You don’t need a data center to get started
You don’t need a PhD to understand how this works
You just need curiosity, a decent GPU, and the willingness to learn

Are you ready to build your own brain?
Because now... you actually can.

Building an Authentication System with MERN

Achal Tiwari — Fri, 09 Aug 2024 07:57:49 +0000

Authentication is a crucial aspect of web development, especially when dealing with user data. If you're looking to deepen your understanding of how to securely handle user passwords, I highly recommend reading my article on how to store user passwords securely. This current guide builds on that foundation and will walk you through setting up a basic authentication system within the MERN stack (MongoDB, Express, React, Node.js). If you're already familiar with password security and bcrypt, you can jump right into this article without needing to read the previous one. In this tutorial, we'll use Express for the backend, MongoDB for storing user data, and JSON Web Tokens (JWT) to secure the authentication process.

Structure of JWT:

1. Setting Up the Express Server

First, let's create an Express server. We'll start by initializing a new Node.js project and installing the necessary dependencies.

mkdir auth-system
cd auth-system
npm init -y
npm install express mongoose bcrypt jsonwebtoken

Next, create an index.js file in the root directory to set up the Express server and connect to MongoDB.
Let’s retrieve our connection string:

Create a MongoDB Atlas account and set up a cluster (this may take a few minutes).
Access Network Access from the sidebar, edit the IP Whitelist entry, and select "Allow Access from Anywhere."
Click on "Connect" and choose "Drivers".
Select "Mongoose" as the driver, and then copy the provided connection string.
Replace the placeholder for the password in the connection string with your actual password.

import express from "express";
import mongoose from "mongoose";
import authRoutes from "./routes/auth.js";
import protectedRoute from './routes/protectedRoute.js';

const mongoURL = 'your-mongodb-connection-string';
const app = express();

app.use(express.json());
app.use("/auth", authRoutes);
app.use("/protected", protectedRoute);

const PORT = process.env.PORT || 3000;

// We'll only start our server once we have successfully connected to the database.
mongoose.connect(mongoURL, () => {
    console.log('Database Connected');
    app.listen(PORT, () => {
        console.log(`Server is running on port ${PORT}`);
    });
});

In this code:

We import necessary modules like express, mongoose, and our route files.
The MongoDB connection string is specified in the mongoURL.
We set up the Express server to use JSON and link it to our authentication and protected routes.
We connect to the MongoDB database using Mongoose.

2. Creating the User Model

Create a models folder, and within it, a User.js file. This file will define the Mongoose schema for storing user data.

import mongoose from 'mongoose';

const userSchema = new mongoose.Schema({
    username: { 
        type: String, 
        unique: true, 
        required: true,
    },
    password: {
        type: String,
        required: true,
    }
});

export const User = mongoose.model("User", userSchema);

Here, we define a simple schema with two fields: username and password. The username is unique to prevent duplicate users, and both fields are required.

3. Implementing Authentication Routes

Next, create a routes folder with two files: auth.js and protectedRoute.js.

auth.js will handle user registration and login:

import express from "express";
import { User } from "../models/User.js";
import bcrypt from "bcrypt";
import jwt from "jsonwebtoken";

const router = express.Router();

// Registration
router.post("/register", async (req, res) => {
    try {
        const { username, password } = req.body;
        const hashedPassword = await bcrypt.hash(password, 10);
        const user = new User({ username, password: hashedPassword });
        await user.save();
        res.status(201).json({ message: "User registered successfully" });
    } catch (error) {
        console.log(error.message);
        res.status(500).json({ error: "Registration Failed" });
    }
});

// User Login
router.post("/login", async (req, res) => {
    try {
        const { username, password } = req.body;
        const user = await User.findOne({ username });
        if (!user) {
            return res.status(401).json({ error: "User Not Found" });
        }
        const passMatch = await bcrypt.compare(password, user.password);
        if (!passMatch) {
            return res.status(401).json({ error: "Wrong Password" });
        }
        const token = jwt.sign({ userId: user._id }, "secretKey", {
            expiresIn: "1h",
        });
        res.status(200).json({ token });
    } catch (err) {
        console.log(err);
        res.status(500).json({ error: err.message });
    }
});

export default router;

Key Concepts:

Registration: We hash the password using bcrypt before storing it in the database.
Login: We compare the hashed password with the stored one, and if they match, we generate a JWT token that the user can use for accessing protected routes. #### 4. Creating a Protected Route Now, let's create a route that is accessible only to authenticated users.

protectedRoute.js:

import express from 'express';
import verifyToken from '../middleware/authMiddleware.js';

const router = express.Router();

router.get('/', verifyToken, (req, res) => {
    res.status(200).json({ message: 'Protected route accessed' });
});

export default router;

authMiddleware.js:
In the middleware folder, create an authMiddleware.js file to verify the JWT token:

import jwt from "jsonwebtoken";

function verifyToken(req, res, next) {
    const token = req.header("Authorization");
    if (!token) return res.status(401).json({ error: "Access denied" });
    try {
        const decoded = jwt.verify(token, "secretKey");
        req.userId = decoded.userId;
        next();
    } catch (error) {
        res.status(401).json({ error: "Invalid token" });
    }
}

export default verifyToken;

Key Concepts:

JWT Verification: We verify the token sent in the request header. If the token is valid, the request is allowed to proceed; otherwise, an error is returned.

5. Testing the System

To test the system, you can use tools like Postman or cURL. Postman is particularly user-friendly and straightforward for testing.

JavaScript on the Server: Node.js

Achal Tiwari — Sun, 28 Jul 2024 16:14:32 +0000

What is Node.js?

Let's dive into Node.js! This article covers many concepts, so grab your favorite coffee or tea, sit back, and let's get started. If you're in a rush, feel free to bookmark it for later. Let's begin!

Introduction to Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment that lets you run JavaScript code on the server side. Here’s why it’s important and how it works:

Node.js is an open-source server environment
An open source server environment is a computer system that processes requests via HTTP
Node.js is a cross-platform, open-source JavaScript runtime environment To understand the magic of Node.js, let's compare it with PHP or ASP in handling file requests:

Traditional PHP or ASP Approach:

Sends the task to the computer's file system.
Waits while the file system opens and reads the file.
Returns the content to the client.
Ready to handle the next request. ##### Node.js Approach:
Sends the task to the computer's file system.
Ready to handle the next request.
When the file system has opened and read the file, the server returns the content to the client. It runs on a single thread using non-blocking, asynchronous programming, which makes it very memory-efficient.

Understanding Node.js Modules

Modules in Node.js are like libraries in JavaScript. Here are the types of modules:

Core Modules: Built into Node.js and available without any additional installation.
Local Modules: Created within your project.
Third-Party Modules: Available through the npm registry and can be installed using npm.

Core Modules

Core modules are part of the Node.js framework. Some examples include:

fs: File System module for interacting with the file system.
http: HTTP module for creating web servers.
path: Path module for handling and transforming file paths.
os: Operating System module for fetching OS-related information.

Example: Using the fs Module

const fs = require('fs');
// Reading a file
fs.readFile('example.txt', 'utf8', (err, data) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(data);
});

Local Modules

They can be a single file or a collection of files organized in a directory.

Example: Creating and Using a Local Module

Create a Local Module

// maths.js
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

module.exports = { add, subtract };

Use the Local Module

// app.js
const math = require('./math');

console.log(math.add(5, 3)); // Output: 8
console.log(math.subtract(5, 3)); // Output: 2

Third-Party Modules

Example: Installing and Using a Third-Party Module

Install the Module

npm install lodash

Use the Installed Module

const _ = require('lodash');

const array = [1, 2, 3, 4, 5];
const reversedArray = _.reverse(array.slice());
console.log(reversedArray); // Output: [5, 4, 3, 2, 1]

Module Caching

Node.js caches modules after they are loaded for the first time.
This means that subsequent require calls for the same module will return the cached version.

Node.js HTTP Module

The http module in Node.js is a core module that provides functionality to create web servers and handle HTTP requests and responses.

const http = require('http');

// Using the `http.createServer()` method to create an HTTP server
const server = http.createServer((req, res) => {  // a callback function to handle incoming requests and send responses.
  res.statusCode = 200; // HTTP status code
  res.setHeader('Content-Type', 'text/plain'); // Set response headers
  res.end('Hello, World!\n'); // Send response
});

// Make the server listen on port 3000
server.listen(3000, '127.0.0.1', () => {
  console.log('Server is running at http://127.0.0.1:3000/');
});

Handling Different Request Methods

HTTP servers can handle different types of requests, such as GET, POST, PUT, and DELETE.
Important Methods:

request.on(event, callback):
- This method is used to set up event listeners for various events that may occur during an HTTP request.
- The event parameter specifies the event to listen for, such as 'data' for when a chunk of data is received, or 'end' for when the entire response has been received.
- The callback function is called when the specified event occurs.
request.end([data], [encoding], [callback]):
- This method is used to send the request to the server.
- It finalizes the request, so no more data can be written to the request.
- Optionally, you can pass data to be sent in the request body, encoding to specify the encoding of the data, and a callback function that will be called when the request has been sent.

const http = require('http');

const server = http.createServer((req, res) => {
  if (req.method === 'GET') {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Received a GET request\n');
  } 
  else if (req.method === 'POST') {\
    let body = '';
    req.on('data', chunk => {
    // chunk will be a buffer like <Buffer 6d 65 73 ... >, 
    // therefore we convered it to String
      body += chunk.toString(); // Convert Buffer to string
    });

    req.on('end', () => {
      res.statusCode = 200;
      res.setHeader('Content-Type', 'application/json');
      res.end(`Received a POST request with body: ${body}\n`);
    });
  } 
  else {
    res.statusCode = 405; // Method Not Allowed
    res.setHeader('Content-Type', 'text/plain');
    res.end('Method Not Allowed\n');
  }
});

// Listen on port 3000
server.listen(3000, '127.0.0.1', () => {
  console.log('Server is running at http://127.0.0.1:3000/');
});

We can use test this code by the use of curl command, to send a post request to our page.

Events

Key Concepts

EventEmitter:
- Core of Node asynchronous event-driven architecture
- It is a module that facilitates communication/interaction between objects in Node.
- Emitter objects emit named events that cause previously registered listeners to be called.
- So, an emitter object basically has two main features:
  - Emitting name events.
  - Registering and unregistering listener functions.

Creating an event

const EventEmitter = require('events');
// Creating an event
const myEmitter = new EventEmitter();

// Define an event listener
const greetListener = (name) => {
  console.log(`Hello, ${name}!`);
};

myEmitter.on('greet', greetListener);

// Emit the event, this will emit the event named 'greet'
// passing 'World' as an argument
myEmitter.emit('greet', 'World');

console.log(myEmitter.listenerCount('greet')); // 1

// Removing the listener
myEmitter.off('greet', greetListener);

// Now, even if you emit the event, nothing will happen
myEmitter.emit('greet', 'World');

console.log(myEmitter.listenerCount('greet')); // 0
console.log(myEmitter.rawListeners('greet')); // []

//-----------Output----------
Hello, World!
1
[ [Function: greetListener] ]
0
[]

Built-in Events

const http = require('http');
const server = http.createServer((req, res) => {
  res.end('Hello, World!');
});

server.on('request', (req, res) => {
  console.log(`Request received: ${req.url}`);
});

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

Serving Static Files

This code will display your image1.png when at localhost:3000/ or 127.0.0.1:3000

const http = require('http');
const fs = require('fs');
const path = require('path');

// Create the server
const server = http.createServer((req, res) => {
  const filePath = path.join(__dirname, req.url === '/' ? 'image1.png' : req.url);
  const extname = path.extname(filePath);
  let contentType = 'text/html';

  // Set content type based on file extension
  switch (extname) {
    case '.js':
      contentType = 'text/javascript';
      break;
    case '.css':
      contentType = 'text/css';
      break;
    case '.json':
      contentType = 'application/json';
      break;
    case '.png':
      contentType = 'image/png';
      break;
    case '.jpg':
      contentType = 'image/jpg';
      break;
  }

  // Read and serve the file
  fs.readFile(filePath, (err, content) => {
    if (err) {
      if (err.code === 'ENOENT') {
        // File not found
        res.statusCode = 404;
        res.setHeader('Content-Type', 'text/html');
        res.end('<h1>404 Not Found</h1>');
      } else {
        // Server error
        res.statusCode = 500;
        res.setHeader('Content-Type', 'text/html');
        res.end('<h1>500 Server Error</h1>');
      }
    } else {
      // Serve the file
      res.statusCode = 200;
      res.setHeader('Content-Type', contentType);
      res.end(content);
    }
  });
});

// Listen on port 3000
server.listen(3000, '127.0.0.1', () => {
  console.log('Server is running at http://127.0.0.1:3000/');
});

URL Module

var url = require('url');  
var adr = 'http://localhost:8080/default.htm?year=2017&month=february';  
var q = url.parse(adr, true);  

console.log(q.host); //returns 'localhost:8080'  
console.log(q.pathname); //returns '/default.htm'  
console.log(q.search); //returns '?year=2017&month=february'  

var qdata = q.query; //returns an object: { year: 2017, month: 'february' }  
console.log(qdata.month); //returns 'february'

Query using URL Parameters

const http = require('http');
const url = require('url');

const server = http.createServer((req, res) => {
  // Parse the URL
  const parsedUrl = url.parse(req.url, true);
  // Extract the pathname (e.g., '/filename.ext')
  const pathname = parsedUrl.pathname;
  // Extract the filename from the pathname
  const filename = pathname.substring(pathname.lastIndexOf('/') + 1);
  // Correctly display the filename with spaces and other special characters
  const decodedFilename = decodeURIComponent(filename); 

  // Set the response header and status code
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/html');

  // Send the response
  res.end(`<h1>Filename: ${decodedFilename}</h1>`);
});

// Listen on port 3000
server.listen(3000, '127.0.0.1', () => {
  console.log('Server is running at http://127.0.0.1:3000/');
});

Open your web browser and navigate to http://127.0.0.1:3000/filename.ext (replace filename.ext with any filename you want to test). The server will display the filename extracted from the URL on the webpage.

Thank you for sticking through this long read. If you have any questions or need further clarification, feel free to reach out in the comments. Happy coding!

ShellCode 1.0

Achal Tiwari — Mon, 22 Jul 2024 09:08:23 +0000

Shellcode

Hey there! Today, we're diving into the fascinating and somewhat intimidating world of shellcode. If you've ever wondered how hackers manage to take control of a compromised machine, shellcode is often a big part of the answer. Let's break it down together.

What is Shellcode?

Shellcode is essentially a piece of code used as a payload in the exploitation of software vulnerabilities. Its primary job is to take control of or further exploit a compromised machine. The term "shellcode" comes from its initial use case, which was to spawn a command shell (think of a command-line interface). But don’t be fooled—it can do a lot more than just that!

Common Goals of Shellcode

Installing a Rootkit or Trojan Horse: These are sneaky programs that either hide the attacker’s presence or give them remote access to your system.
Stopping Antimalware Programs: This makes sure the attack goes undetected for as long as possible.
Obtaining Sensitive Data: Passwords, financial information, or personal data.
Downloading More Malicious Files: This helps further compromise the targeted device.

How Does Shellcode Work?

Shellcodes are injected directly into the computer's memory. They are generally written in assembly language, which makes them really good at sneaking past antivirus and Endpoint Detection and Response (EDR) systems. However, plain shellcode can be spotted by antivirus software since these programs have databases full of known malicious code. To stay hidden, shellcode often gets encrypted using various cryptographic techniques.

Breaking Down a Shellcode Exploit

A shellcode exploit has two main parts:

Exploitation Technique: This is how the attacker inserts the shellcode and makes sure the vulnerable program runs it.
Payload: This is the part that actually executes the attacker's malicious code.

Example: Buffer Overflow

Let’s go through a classic example of how shellcode is used: a buffer overflow.

Step-by-Step: Buffer Overflow

Buffer Overflow: Imagine an attacker sends more data than a buffer can handle. This excess data spills over into adjacent memory.
Overwrite Return Address: Eventually, this overflow reaches and overwrites the return address on the stack—the place where the program knows where to go next after finishing the current function.
Injected Shellcode: The attacker’s shellcode is part of the overflow data, positioned at a specific memory location.
Shell Execution: When the program tries to return from the function, it jumps to the shellcode instead, executing the attacker's malicious actions.

Types of Buffer Overflows

Stack-Based: Exploits the application's stack.
Heap-Based: Targets the application’s heap memory space. ###### Crafting a Successful Exploit Writing the shellcode is usually the easier part. The real challenge is figuring out where the shellcode is in memory and controlling the Extended Instruction Pointer (EIP) register to make sure the shellcode runs.

Writing Shellcode

Shellcode Writing: This is the actual malicious code.
Finding Shellcode Address: Knowing where in memory the shellcode resides.
EIP Control: Exploiting a vulnerability to overwrite the EIP with the shellcode’s address.
Execution: Redirecting execution to the shellcode.

Different Types of Shellcode Exploits

Local vs. Remote Shellcode

Local Shellcode: Used when the attacker has physical access to the machine.
Remote Shellcode: Targets a process on another machine over a network.

Sometimes, there's limited space in the buffer to inject the entire payload. Here are some techniques to get around this:

Staged Shellcode: The first stage is small and simple, just enough to download and execute the larger second stage.
Egg Hunter Shellcode: A tiny "hunter" piece of code searches for the larger "egg" shellcode in memory and executes it.
Omelette Egg Hunter Shellcode: Finds multiple small "eggs" and rebuilds them into a single executable block.
Download and Execute: Instructs the target to download and run a malicious file from the internet.

Understanding shellcode is crucial whether you're a security professional or a developer. It helps you protect systems against these sophisticated attacks. By recognizing the techniques attackers use, you can better defend your digital environment.

I hope this provided you with a clear understanding of what shellcode is and how it operates. In our next article, we'll dive into writing shellcode and exploring related concepts in greater detail. Happy coding!

How to Store User Passwords Securely

Achal Tiwari — Mon, 22 Jul 2024 06:58:11 +0000

Storing passwords securely is crucial for maintaining user privacy and data integrity. So, how should you store a password if you were asked to do so? The simplest way might seem to store it in plain text, but we all know that is not secure. Should we use encryption or hashing? Let's explore these methods together in our article today.

Plain Text Passwords

Alright, let's start with the most basic approach: plain text. Imagine you just write down all the passwords exactly as users enter them. It's simple, right? But here's the problem: if anyone gets access to this list, they can see all the passwords right away. It’s like leaving the keys to your house under the doormat. Not a good idea!

Encryption

Next, let's talk about encryption. Encryption is a process where we take a password and transform it into a different format using an algorithm. Think of it as a secret code. But here's the catch: encryption is reversible. If someone figures out the code (or gets the key, which you have to store somewhere), they can decrypt the password.

Experiment: Simple Encryption

Imagine we use something simple like ROT13, which just shifts each letter by 13 places in the alphabet. "password" becomes "cnffjbeq". But if someone knows we used ROT13, they can easily reverse it. Even with more complex encryption, if an attacker gets the key, they can decrypt all the passwords. So, reversible encryption isn't ideal for password storage.

Hash Functions

Now, let's move on to hash functions. Hashing takes a password and transforms it into a fixed-size string of characters, which looks nothing like the original password. The key here is that hashing is one-way: you can't easily reverse it to get the original password.

Experiment: Basic Hashing

Let's try using a simple hash function like SHA-256. Here's a quick example in Python:

import hashlib

password = "password123"
hash_object = hashlib.sha256(password.encode())
hashed_password = hash_object.hexdigest()
print(hashed_password)

You’ll get a long, unique string. But even with secure hashes like SHA-256, there's a problem: they are very fast to compute. An attacker can try billions of passwords per second.

Enhancing Security with Salt, Pepper, and Iteration

To make things harder for attackers, we can add some extra layers of security: salt, pepper, and iteration.

Salt

A salt is a unique random value added to each password before hashing. This ensures that even if two users have the same password, their hashed passwords will be different.

Experiment: Adding Salt

import os

salt = os.urandom(16)  # Generate a random salt
password = "password123"
hash_object = hashlib.sha256(salt + password.encode())
hashed_password = hash_object.hexdigest()
print(hashed_password)

Now, each time you run this, you'll get a different result because the salt is random. This makes it much harder for attackers to use precomputed hash tables.

Pepper

A pepper is a common secret value added to all passwords. Unlike salt, the pepper is stored separately from the database. This adds an extra layer of security because an attacker would need both the database and the pepper to crack the passwords.

Iteration

Iteration means hashing the password multiple times. This makes each hash calculation slower, which significantly increases the time required for attackers to crack passwords.

Experiment: Adding Iteration

iterations = 100000
hash = hashlib.sha256((salt + password.encode())).hexdigest()
for _ in range(iterations - 1):
    hash = hashlib.sha256(hash.encode()).hexdigest()
print(hash)

By increasing the number of iterations, you make it more computationally expensive for an attacker to guess passwords.

Using Specific Functions

Instead of creating our own hashing algorithms, we can use established functions designed specifically for password storage, like bcrypt, scrypt, and Argon2. These functions already incorporate salt, iteration, and other security measures to resist attacks effectively.

Bcrypt

Let's dive into bcrypt, one of the most popular password hashing functions. Bcrypt is based on the Blowfish cipher and is designed to be slow to compute, making it harder for attackers to crack passwords.

Experiment: Using Bcrypt

Here's how you can use bcrypt in Python:

import bcrypt

# Generate a salt and hash a password
salt = bcrypt.gensalt()
hashed_password = bcrypt.hashpw(b'password123', salt)
print(hashed_password)

# Verify a password
is_correct = bcrypt.checkpw(b'password123', hashed_password)
print(is_correct)  # True

With bcrypt, each hash includes a unique salt, and you can adjust the "work factor" to make the hashing process slower, enhancing security.

Why Bcrypt is Effective

Bcrypt’s strength lies in its ability to adjust the cost factor, which means you can make the hashing process more computationally intensive as hardware improves. This future-proofs your password security, making it more resistant to attacks over time.

Famous Cases of Hash Cracking

To understand why all this matters, let's look at some real-world examples:

LinkedIn (2012): LinkedIn used SHA-1 without salt, leading to the recovery of 90% of the leaked passwords in just three days.
Adobe (2013): Encrypted passwords without proper hashing led to a massive breach affecting 38 million users.
MySpace (2016): Use of unsalted SHA-1 hashes resulted in the compromise of 360 million accounts.

I hope this hands-on exploration helped you understand why and how to store passwords securely. Happy Coding!

Redux : State Management Tool

Achal Tiwari — Sun, 07 Jul 2024 09:48:11 +0000

Hello! Today, we are going to explore how to manage state in production-ready projects using Redux. For those who aren't familiar with state management, let's break it down.

What is State Management?

State management is about handling the state of various user interface elements, such as text fields, buttons, and other interactive components in a graphical user interface. To get a clearer understanding of state management and React, check out the Context API. You can read the official docs or my article on it.

What is Redux?

Redux is a pattern and library for managing and updating application state, using events called "actions".

It serves as a centralized store for state that needs to be used across your entire application, with rules ensuring that the state can only be updated in a predictable fashion.

Key Concepts of Redux

Store: The store holds the state of your application.
Actions: Actions are plain JavaScript objects that describe what happened.
Reducers: Reducers specify how the application's state changes in response to actions.

Setting Up Redux in a React App

Let's start by setting up Redux in a simple React app.

npx create-react-app my-redux-app
cd my-redux-app
npm install redux react-redux

Set Up the Redux Store

Create a store.js file:

import { createStore } from 'redux';
// Initial state
const initialState = {
  count: 0,
};
// Reducer
const reducer = (state = initialState, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return { ...state, count: state.count + 1 };
    case 'DECREMENT':
      return { ...state, count: state.count - 1 };
    default:
      return state;
  }
};

// Create store
const store = createStore(reducer);

export default store;

Provide the Store to Your App

Wrap your app with the Provider component from react-redux in index.js:

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import store from './store';
import App from './App';

ReactDOM.render(
// this wrap helps all your components to get access of your store
  <Provider store={store}> 
    <App />
  </Provider>,
  document.getElementById('root')
);

Connect Components to Redux

Create a Counter.js component:

import React from 'react';
import { useSelector, useDispatch } from 'react-redux';

const Counter = () => {
//Selector helps you to get access of data based on provided state
  const count = useSelector(state => state.count); 
// useDispatch allows React components to dispatch actions to the // Redux store.
  const dispatch = useDispatch();

  return (
    <div>
      <h1>Count: {count}</h1>
// we have made switch cases based on action type, therefore we 
// need to pass type along with dispatch
      <button onClick={() => dispatch({ type: 'INCREMENT' })}>Increment</button>
      <button onClick={() => dispatch({ type: 'DECREMENT' })}>Decrement</button>
    </div>
  );
};

export default Counter;

Add the Counter component to your App.js:

import React from 'react';
import Counter from './Counter';

function App() {
  return (
    <div className="App">
      <Counter />
    </div>
  );
}

export default App;

Now, this approach is a bit complex, but it's essential to understand the fundamentals of Redux and how it works. In the second part, we'll simplify things by using redux-toolkit. Let's dive into the easier way of managing state with Redux Toolkit!

1. Install Redux Toolkit

npm install @reduxjs/toolkit

2. Set up the store with Redux Toolkit

Update your store.js file

import { configureStore, createSlice } from '@reduxjs/toolkit';

//A slice is a collection of actions and reducer logic for a single feature in an app

// Create a slice
const counterSlice = createSlice({
  name: 'counter',
  initialState: { count: 0 },
  reducers: {
    increment: state => { state.count += 1; },
    decrement: state => { state.count -= 1; },
  },
});

// Export actions
export const { increment, decrement } = counterSlice.actions;

// Create store
const store = configureStore({
  reducer: counterSlice.reducer,
});

export default store;

3. Update the Component

Update the Counter.js

import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { increment, decrement } from './store';

const Counter = () => {
  const count = useSelector(state => state.count);
  const dispatch = useDispatch();

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <button onClick={() => dispatch(decrement())}>Decrement</button>
    </div>
  );
};

export default Counter;

This is it, you are done, now go and make real world application to have practice with redux. Happy Coding!

Context API

Achal Tiwari — Thu, 04 Jul 2024 09:28:03 +0000

What is Context API?

The Context API is a React feature that allows you to share state across multiple components without having to pass props down manually at every level. It’s like a global variable that all components in a tree can access but in a more efficient and easy way.

Let's first understand the key terms before moving on to the example. If you don't fully grasp the concepts right away, don't worry. Proceeding to the example will help clarify how everything works together.

Key Concepts of the Context API

Context Creation: Using createContext to create a context object.
Provider: Using Context.Provider to pass the state to child components.
Consumer: Using useContext to access the state in any component.

To help you understand the Context API in a practical way, we'll build a very basic login page. In this example, when you type your name and submit it, you'll be greeted with your name. This simple example focuses on the Context API without the complexity of a larger application. I have also explained the code lines in the comments.

I will provide the names of all the files to make it easy for you to follow along. You can create these files in your src directory and check the functionality yourself.

Setting Up the Context

UserContext.js
First, we create a context. This context will hold the user data.

import React, { createContext } from 'react';

const UserContext = createContext();

export default UserContext;

UserContextProvider.jsx
Next, we create a provider component. This component will wrap around parts of our app that need access to the user data.

import React, { useState } from 'react';
import UserContext from './UserContext';

const UserContextProvider = ({ children }) => {
  const [user, setUser] = useState(null);

  return (
  // whatever values you will give below,
  //will be shared to anyone who will call them using useContext()
    <UserContext.Provider value={{ user, setUser }}>
      {children}
    </UserContext.Provider>
  );
}

export default UserContextProvider;

Using the Context in Our App

App.jsx
In our main App component, we wrap the relevant parts of our app with the UserContextProvider.

import React from 'react';
import UserContextProvider from './UserContextProvider';
import Login from './Login.jsx';
import Profile from './Profile.jsx';

function App() {
  return (
// This wrapping let's every children compenent to have the access
// to values using the useContext hook
    <UserContextProvider>
      <h1>Context Tutorial</h1>
      <Login />
      <Profile />
    </UserContextProvider>
  );
}

export default App;

Login.jsx
In the Login component, we use the useContext hook to access and update the user data.

import React, { useState, useContext } from 'react';
import UserContext from './UserContext';

function Login() {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');

  const { setUser } = useContext(UserContext);
  // Here, we extract the setUser function from the UserContext using the useContext hook.
  // Remember, we passed the user and setUser values in the UserContext.Provider:
  // <UserContext.Provider value={{ user, setUser }}>, which makes them accessible to any component 
  // that uses the useContext hook with UserContext.
  const handleSubmit = (e) => {
    e.preventDefault();
    setUser({ username, password });
  };

  return (
    <div>
      <h2>Login</h2>
      <input 
        type='text' 
        value={username} 
        onChange={(e) => setUsername(e.target.value)}
        placeholder='username' 
      />
      <input 
        type='password'
        value={password} 
        onChange={(e) => setPassword(e.target.value)} 
        placeholder='password' 
      />
      <button onClick={handleSubmit}>Submit</button>
    </div>
  );
}

export default Login;

Profile.jsx
In the Profile component, we use the useContext hook to access the user data.

import React, { useContext } from 'react';
import UserContext from './UserContext';

function Profile() {
  const { user } = useContext(UserContext);

  if (!user) return <div>Login above to have your name here</div>;

  return <div>Hello {user.username}</div>;
}

export default Profile;

You will see this interface when you run your React App using the above files.

After you enter a username and password(anything as there are no checks), this page will greet you with that username.

Here is the Summary of Context API

This image and the one at the very top is form a youtube video by Code Bootcamp.Feel free to ask questions in the comments. I'll be happy to answer them. Happy coding!

React 101

Achal Tiwari — Wed, 03 Jul 2024 13:36:40 +0000

This article assumes familiarity with React coding, particularly in using states and other essential features.

State

State: Component-specific memory in React used to track and manage dynamic data within a component.
Dynamic Interaction: State allows components to change what’s displayed on the screen based on user interactions or other events.

Common Use Cases

Form Inputs: State is used to remember and update the current value of an input field as a user types.
Image Carousels: State tracks the currently displayed image and updates it when the user clicks “next” or “previous”.
Shopping Carts: State manages the items in the shopping cart, adding new products when the user clicks “buy”.

React batches state updates. It updates the screen after all the event handlers have run and have called their set functions. This prevents multiple re-renders during a single event. In the rare case that you need to force React to update the screen earlier use flushSync.

Queuing a Series of State Updates

Setting a state variable will queue another render. But sometimes you might want to perform multiple operations on the value before queuing the next render

// This is a general Interview question
import { useState } from 'react';
export default function Counter() {
  const [number, setNumber] = useState(0);
  return (
    <>
    // M-1
      <h1>{number}</h1>
      <button onClick={() => {
        setNumber(number + 1);
        setNumber(number + 1);
        setNumber(number + 1);
      }}>+3</button>
    // M-2
      <h1>{number}</h1>
      <button onClick={() => {
        setNumber(n => n + 1);
        setNumber(n => n + 1);
        setNumber(n => n + 1);
      }}>+3</button>
    </>

  )
}

I want you to think about how will M-1 and M-2 perform.

M-1 code will only increment the number by 1

Why?

Each render’s state values are fixed, so the value of number inside the first render’s event handler is always 0, no matter how many times you call setNumber(1):

React waits until all code in the event handlers has run before processing your state updates. This is why the re-render only happens after all these setNumber() calls.

But M-2 code can do the increment by 3