DEV Community: Anurag Bagri

JWT vs Cookies in Next.js: What Should We Really Use for Authentication?

Anurag Bagri — Fri, 26 Dec 2025 14:25:49 +0000

Authentication looks simple on the surface — until we build a real Next.js application with SSR, middleware, and protected routes.

Most developers start with JWT, then run into issues such as:

Tokens not being available on first page load
Authentication breaking during SSR
Security concerns with localStorage
Confusion around cookies vs tokens So let’s clear everything properly, from the ground up, specifically in the context of Next.js.

What Is JWT?

JWT (JSON Web Token) is a compact, self-contained token used to transfer claims between parties.

A JWT consists of three parts:

"header.payload.signature"

What it contains

Header → token type and signing algorithm
Payload → user data such as userId, roles, expiry
Signature → ensures integrity and authenticity

Key properties of JWT

Stateless (the server does not store sessions)
Usually sent via an Authorization header

Commonly stored in:

localStorage (unsafe)
memory (temporary)
cookies (preferred)

JWT itself is not the problem.
The real issue is how and where we store it.

What Are Cookies?

Cookies are browser-managed key–value storage that automatically travel with HTTP requests.

Example format:

"Set-Cookie: auth_token=xyz; HttpOnly; Secure; SameSite=Strict"

Key properties of cookies

Automatically sent with every request
Available during server-side rendering

Can be configured as:

HttpOnly (JavaScript cannot access it)
Secure (HTTPS only)
SameSite (CSRF protection)

Cookies are not an authentication mechanism.
They are a transport and storage mechanism.

JWT vs Cookies — The Most Important Clarification

JWT and cookies are not competitors.This misunderstanding causes most authentication bugs.JWT defines what proves identityCookies define how that proof is stored and sent.

We can:

Store JWT inside cookies (best approach)
Send JWT via headers (problematic in Next.js)
Store sessions inside cookies

So the real comparison is not JWT vs cookies, but:

JWT in headers vs JWT in cookies

Why JWT Alone Fails in Next.js

Next.js is not just a frontend framework.
It executes code in multiple environments:

Server Components
Route Handlers
Middleware
SSR / SSG
Client Components

The Core Problem

JWT stored in:

localStorage
sessionStorage
JavaScript memory

is not accessible on the server.This means:

The first request has no auth context
SSR cannot fetch protected data
Middleware cannot validate users
Auth-based redirects fail
The SSR Problem (The Real Reason Cookies Win)

Consider a user visiting a protected route like /dashboard. With JWT in localStorage the server renders the page. The server has no access to the JWT. The page renders as unauthenticated and client hydrates. JWT is read from storage so the data is refetched.

This causes:

UI flickering
Security inconsistencies
Poor user experience

With Cookies

The request reaches the server
Cookies are automatically attached
The server validates authentication
Protected data loads on the first render
This single point explains why cookies dominate in Next.js authentication.
Extra Capabilities Cookies Provide (Beyond JWT)
Cookies unlock platform-level capabilities that JWT alone cannot.

Middleware Authentication

Because cookies are available at the edge, middleware can read them and make routing decisions before a page renders.

Example logic (not code):

"We read the auth cookie in middleware and redirect unauthenticated users before rendering protected routes."

This is impossible with localStorage.

Security by Design

Cookies provide:

HttpOnly protection against XSS
SameSite protection against CSRF
Secure flag for HTTPS-only transmission
JWT stored in localStorage provides none of these protections.
Works Everywhere in Next.js

Cookies are accessible in:

Server Components
Route Handlers
Middleware
API Routes
SSR

This creates one unified authentication model across the entire application.

Why Next.js Apps Prefer Cookies (Even When Using JWT)

Most production-grade Next.js apps follow this flow:

"User logs in → Server generates JWT → JWT stored in HttpOnly cookie → Cookie sent automatically → Server validates JWT"

So JWT is still used, but cookies act as the delivery and storage layer.

This approach gives us:

Stateless authentication
SSR compatibility
Strong security guarantees
Cleaner architecture

When JWT in Headers Still Makes Sense
JWT sent via headers can still be useful for:

Pure backend APIs
Mobile applications
Third-party integrations
Systems without SSR

But for Next.js full-stack applications, cookies are simply the better choice.

Cookies solve:

First-request authentication
Server-side authorization
Middleware protection
Major security vulnerabilities

JWT does not disappear —
it just stops being misused.

Understanding AI: From LLMs to MCP

Anurag Bagri — Sun, 09 Nov 2025 18:10:02 +0000

Large Language Models (LLMs) form the foundation of today’s AI. At their core, an LLM like GPT-4 processes tokens (sub-word text units) through a deep neural network. Each token is converted into a high-dimensional embedding (a numeric vector capturing semantic meaning). For example, the sentence “Hello world” might be broken into tokens like "Hello", "Ġworld" and each token is mapped to a vector of hundreds or thousands of dimensions. These embeddings allow the model to understand relationships between words. GPT-4 also has a large context window (e.g. up to 8K or even 32K tokens in extended versions), meaning it can “remember” and attend to that many tokens in a single conversation. In practice, you might use GPT-4 in code like this:

from openai import OpenAI
 client = OpenAI(api_key="YOUR_KEY")
 response = client.chat.completions.create(
     model="gpt-4",
     messages=[
         {"role": "system", "content": "You are a helpful assistant."},
         {"role": "user",   "content": "Explain the concept of a context window."}
     ]
 )
print(response.choices[0].message.content)

Here, GPT-4 reads the system and user messages as tokens, embeds them into vectors, and generates a response. The context window lets the model incorporate long conversations or documents into its output. If a conversation exceeds the window size, older tokens are dropped or summarized, which can lead to loss of information. Large context windows address this limitation by allowing more prior text to influence the output. Embeddings and vector representations also enable similarity comparisons: two sentences with similar meaning will have vectors that are close under measures like cosine similarity.

Agents (LangChain)

As LLMs matured, developers needed ways to act, not just chat. Agents—often built with frameworks like LangChain—turn LLMs into dynamic actors that reason, make decisions, and use external tools. Instead of a single prompt-response, an agent runs in a loop: it analyzes input, maybe calls a function or searches the web, and then decides next steps. LangChain lets you create an agent with built-in reasoning and tool usage. For example, you might give an agent a search tool and a calculator, then ask it a question:

from openai import OpenAI
client = OpenAI(api_key="YOUR_KEY")
response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Explain the concept of a context window."}
    ]
)
print(response.choices[0].message.content)

Agents (LangChain)

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def web_search(query: str) -> str:
    # Imagine this calls an actual search API
    return f"Top news results for '{query}'."

@tool
def calculator(expression: str) -> str:
    try:
        return str(eval(expression))
    except:
        return "Calculation error."

agent = create_agent(model="gpt-4", tools=[web_search, calculator])
result = agent.invoke({"input": "Who won the World Cup in 2022 and what is 2023 - 1980?"})
print(result)

Here, the agent uses GPT-4 as its reasoning model and has two tools. When asked a compound question, the agent can first use the web_search tool to find the World Cup winner, then use calculator to compute the arithmetic. This surpasses a standalone LLM by allowing tool use and multi-step thinking. Agents address LLM limitations (like not having up-to-date data or complex reasoning) by orchestrating the model’s outputs with external knowledge and logic.

Prompt Engineering

Even with a powerful LLM, how you frame the question matters a lot. Prompt engineering is the practice of designing prompts to get the best results. Effective strategies include giving the model a clear role (using a system message), providing examples (few-shot learning), and encouraging step-by-step reasoning. For instance, you might use chain-of-thought prompting to get a thorough answer:

messages = [
    {"role": "system", "content": "You are a brilliant tutor."},
    {"role": "user",   "content": "Explain the solution step by step to: 2345 * 789."}
]
response = client.chat.completions.create(model="gpt-4", messages=messages)
print(response.choices[0].message.content)

In this example, specifying a helpful persona encourages the model to provide clear steps. Key prompt tips include:

Be explicit: Clearly specify the task and format.

Use examples: Show input/output pairs to guide the model (few-shot).

Structured prompts: Ask for bullet points, numbered steps, or specific styles (e.g. “answer as JSON”).

Clarify the scope: Tell the model what to ignore or include to focus its reasoning.

Prompt engineering fills gaps where raw LLM outputs might be unfocused or hallucinated. By carefully crafting prompts, we steer GPT-4 to use its capabilities effectively and avoid previous issues like one-line answers or irrelevant details.

Vector Databases

LLMs have fixed context limits and no built-in memory, so we use vector databases to store and retrieve knowledge. In a vector DB, each piece of text (a document, paragraph, or chunk) is converted into an embedding vector (often 768 or 1536 dimensions). For example, using OpenAI’s embedding API:

embedding = client.embeddings.create(
    model="text-embedding-ada-002", input="Apple is looking at buying a UK startup for $1 billion"
)
vector = embedding.data[0].embedding  # a 1536-dimensional list of floats

These vectors go into a database (like Pinecone, Chroma, or FAISS). When a query comes, we embed the query and compute similarity scores (usually cosine similarity or dot product) against stored vectors. The top-scoring chunks (often overlapping segments of larger text) are returned. Chunk overlap means when splitting long documents into pieces, we overlap the splits slightly to avoid cutting apart relevant phrases.

The semantic meaning of vectors is key: similar content yields close vectors, so even if the wording changes, retrieval still finds relevant info. Dimensionality impacts how much nuance can be captured; typical embeddings use hundreds or thousands of dimensions. Vector DBs solve context-limit issues by effectively expanding an LLM’s memory: we can retrieve past data or knowledge on-the-fly and feed it into the model.

Retrieval-Augmented Generation (RAG)

Retrieval-Augmented Generation combines vector search with LLM answers to produce grounded, accurate outputs. In RAG, a user’s query triggers a semantic search in a vector database; the retrieved documents become context for the LLM’s answer. For example:

# Step 1: Embed the query
query = "Who won the World Cup in 2022?"
q_embed = client.embeddings.create(model="text-embedding-ada-002", input=query)["data"][0]["embedding"]

# Step 2: Search the vector DB (pseudocode)
results = vector_db.search(q_embed, top_k=3)  # returns top 3 relevant chunks

# Step 3: Construct a prompt with retrieved info
documents_text = "\n".join([doc.text for doc in results])
messages = [
    {"role": "system", "content": "You answer using provided documents."},
    {"role": "user",   "content": f"Documents: {documents_text}\n\nQuestion: {query}"}
]
answer = client.chat.completions.create(model="gpt-4", messages=messages)
print(answer.choices[0].message.content)

Here, RAG grounds GPT-4’s answer with real documents. It addresses limitations of plain LLMs: it counters hallucinations by providing factual context, and it handles knowledge beyond the model’s training cutoff. The trade-off is that RAG requires an external knowledge base and careful prompt construction to ensure the model uses the retrieved content correctly.

LangGraph for AI Workflows

As projects grow complex, simple chains and agents can become hard to manage. LangGraph introduces graph-based workflows for AI pipelines. Instead of linear chains, you define nodes (tasks or agents) and edges (data flow). This graph structure brings flow control, branching, and state management into AI systems.

For example, you might have a workflow where one node queries GPT-4 for ideas, another node checks a knowledge base, and a third node synthesizes answers. LangGraph allows branches: if a condition is met, the graph can take one path or another. It also includes memory: using annotations, you can preserve state across runs or checkpoint progress. Human-in-the-loop nodes can pause the flow for manual input, and you can stream intermediate results for real-time monitoring.

A simplified pseudo-code of a LangGraph workflow might look like:

from langchain.graphs import StateGraph

def idea_node(state):
    text = state["input_text"]
    return {"ideas": GPT4_chain(text)}

def write_node(state):
    ideas = state["ideas"]
    return {"draft": GPT4_chain(ideas)}

workflow = StateGraph()
workflow.add_node("generate_ideas", idea_node)
workflow.add_node("write_draft", write_node)
workflow.add_edge("generate_ideas", "write_draft")
result = workflow.invoke({"input_text": "Write an article about AI ethics."})
print(result["draft"])

In practice, LangGraph (especially in its JavaScript form) supports advanced features like error recovery and modular agent collaboration. By structuring workflows as graphs, LangGraph addresses the limitation of linear or ad-hoc pipelines, making AI systems more maintainable and scalable.

Model Context Protocol (MCP)

As agents rely more on tools, a standard way to integrate those tools becomes crucial. The Model Context Protocol (MCP) is an emerging open standard for exactly this purpose. MCP defines a protocol where tools run in separate processes or servers, and LLMs communicate with them through a standardized JSON schema. This separates tool implementation from agent logic, making tools language-agnostic and interoperable.

For example, a MCP math server might expose an “add” and “multiply” tool. Your GPT-4 agent can call them without knowing internal details. In LangChain, you can use langchain-mcp-adapters to connect to these services:

from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain.agents import create_agent

# Define MCP servers for math and weather tools
client = MultiServerMCPClient({
    "math": {
        "transport": "stdio", 
        "command": "python",
        "args": ["math_server.py"]
    },
    "weather": {
        "transport": "streamable_http",
        "url": "http://localhost:8000/mcp"
    }
})
tools = client.get_tools()  # Load tools from both servers
agent = create_agent("gpt-4", tools=tools)

response = agent.invoke({"input": "If it's 20°C in London, what's that in °F?"})
print(response)

In this setup, the agent sees “math:add” or “weather:get_weather” as tools. MCP ensures each tool call follows the same protocol, handling communication details. This addresses previous limitations where each tool library had its own interface. With MCP, building an AI system with many specialized tools becomes standardized, safer, and easier to maintain.

Good Last words

Together, these components form a robust AI development stack. Each innovation addresses a specific bottleneck: LangChain (and its agents) orchestrates complex LLM workflows and tool usage;prompt engineering ensures precise control over GPT-4’s outputs; vector databases and RAG overcome context-window and knowledge limitations by injecting relevant data into the model’s input; LangGraph enables dynamic, stateful execution for multi-agent applications; and MCP provides a unified, scalable way to integrate external context. In combination, these layers empower GPT-4/ChatGPT systems to scale gracefully and adapt in real time, yielding AI applications that are scalable, dynamic, and deeply context-aware.

API Protocols Unpacked: REST, GraphQL, tRPC, and gRPC

Anurag Bagri — Sun, 19 Oct 2025 17:03:35 +0000

Hello guys! Ever wondered how apps like your favorite social feed or ride-sharing service fetch data seamlessly? It's all thanks to API protocols—the rules that let software talk efficiently. In this quick guide, we'll define them, spotlight four popular ones with examples, explore their setups, match them to use cases, compare head-to-head, and end with tips. Think of it as picking the best bike for your commute: each has its perks for speed or comfort. Let's keep it snappy and fun!

API Protocols Basics
API protocols are standardized rules for how applications exchange data over networks, covering message formats (like JSON), transport methods (e.g., HTTP), and error handling to ensure reliable, secure chats between services. They're the "language" APIs use to connect everything from mobile apps to databases, preventing mix-ups in the digital world. For instance, when we search Netflix, a protocol dictates how the app requests and gets movie suggestions without overload.

Meet the Protocols: Definitions and Overviews
Each one brings a unique flavor to API design.

REST: The Web Standard
REST (Representational State Transfer) is a flexible style using HTTP for stateless resource interactions—think GET for reading data, POST for creating it. It's like a library catalog: search /books to browse, add via POST. Simple and widely supported.

GraphQL: The Custom Query Tool
GraphQL, from Facebook, lets clients request exact data via a single endpoint and typed schema, avoiding extra fluff. Imagine ordering sushi: pick just rolls and rice, no sides. It supports queries, mutations, and real-time subs.

tRPC: TypeScript's Quick Helper
tRPC (TypeScript RPC) builds type-safe APIs for JS/TS stacks, calling server functions like local code with auto-inferred types. No schema hassles—it's like a direct video call to your backend for a Next.js dashboard.

gRPC: The Speedy Streamer
gRPC, Google's framework, uses HTTP/2 and binary protobufs for fast, contract-based calls, including streams. Picture a live sports feed: data flows bidirectionally without lags, ideal for microservices.

Their Architectures: How They Tick
Quick looks at the inner workings.

REST Setup
Client-server with URIs for resources; stateless HTTP requests/responses in JSON. Layers like caches keep it scalable, but nested data needs multiple calls (e.g., /users then /users/1/posts).

GraphQL Setup
Schema defines types; resolvers fetch data for one /graphql endpoint. Queries run in parallel—e.g., { user { posts { title } } } grabs nested info efficiently.

tRPC Setup
Code-first routers on server; client proxies infer types over HTTP/JSON. A call like api.posts.list() feels seamless, with built-in error handling.

gRPC Setup
.proto files generate code for services; HTTP/2 multiplexes streams. Unary or bidirectional RPCs shine, like a chat app's ongoing message exchange.

Use Cases: Where They Fit Best

REST for Everyday Wins
Great for CRUD apps like e-commerce sites (fetch /products) or public APIs—easy to debug and scale for read-heavy tasks.

GraphQL for Smart Flexibility
Suits data-rich apps like social platforms (query user feeds precisely) or real-time dashboards, cutting over-fetching.

tRPC for Fast TS Builds
Ideal for prototypes or full-stack React apps, speeding dev with types—think internal tools fetching user data instantly.

gRPC for High Stakes
Powers microservices or IoT (live location streams in rideshares), excelling in low-latency, high-volume scenarios

Final Thoughts: Choose Your Adventure
These protocols—REST for simplicity, GraphQL for control, tRPC for TS ease, gRPC for performance—make API building exciting and efficient. App's success hinges on matching the right one to your goals

happy coding!

Stateful vs stateless - backends and frontends

Anurag Bagri — Sat, 11 Oct 2025 10:42:27 +0000

When I first started learning web development, I often came across the terms “stateful” and “stateless” — especially when people talked about backend APIs, frontend apps, or server design. It sounded fancy at first, but once I understood what state actually means, everything made sense.

So let’s start from the basics.

What Do “Stateful” and “Stateless” Mean?

In simple terms, state means remembering something.

If a system remembers what happened earlier — it’s stateful.

If it forgets everything after each interaction — it’s stateless.

Think of it like talking to two different shopkeepers:

A stateful shopkeeper remembers what you bought last week.

A stateless one treats you like a brand-new customer every single time.

Frontend: Stateful vs Stateless

In the frontend, state refers to the UI data stored in the browser or app memory — like user inputs, selections, all variables or data fetched from APIs.

Stateful Frontend

A stateful frontend keeps track of what’s going on — it remembers the user’s actions or data even when things change.
Example:

A React app that stores login info in context or Redux store.

A chat app that maintains active messages or typing state without reloading.

A game that remembers current score and progress.

These apps store data in state variables or local storage — so they know what’s happening between renders.

Stateless Frontend

A stateless frontend doesn’t remember anything. Each time we load the page, it starts fresh.
Example:

A static HTML site built with plain HTML/CSS/JS that just fetches data and displays it without saving any context.

A simple portfolio website or landing page — no dynamic memory or user context.

Backend: Stateful vs Stateless

The same idea applies to the backend too, but here it’s about server memory and client sessions.

Stateful Backend

A stateful backend stores user data or sessions on the server between requests.
Example:

Traditional applications using sessions or cookies to remember the user (like older PHP apps).

WebSocket servers that keep a live connection with each client — like chat or multiplayer games.

Any server that needs to maintain long-term user context (like logged-in sessions or ongoing transactions).

The downside? It’s harder to scale — because every user’s data lives on a specific server instance. And we know that how much

Stateless Backend

A stateless backend doesn’t store anything about previous requests. Each API call is independent.
Example:

REST APIs or serverless functions (like AWS Lambda, Firebase Functions).

Each request carries all the info needed (like tokens in headers).

Perfect for horizontal scaling, as any server can handle any request.

This is why most modern backends are stateless — they’re simpler to scale, cache, and deploy.

What’s Preferred (and Why)

On the Frontend

Frontend apps are usually stateful, because they handle user interactions, UI updates, and temporary storage of data.
Without state, your app would feel static and disconnected.
However, developers manage it carefully — too much state makes debugging painful.
That’s why tools like React, Redux, Recoil, or Zustand exist to manage state efficiently.(Recoil my personal fav)

On the Backend

Backends are generally preferred to be stateless.
Why? Because:

They’re easier to scale horizontally.

Requests can be distributed across multiple servers.

No dependency on specific instances or memory.

When backend systems need to “remember” something, they usually offload it to a database, cache, or token-based session — rather than keeping it in memory.

That’s the sweet spot where most modern apps live today.

Solana Architecture: Why It’s So Fast

Anurag Bagri — Sat, 04 Oct 2025 10:39:39 +0000

When people talk about Solana handling up to 65,000 transactions per second (TPS) compared to Ethereum’s 20–30 TPS, the secret lies not in a single feature, but in a carefully designed architecture.

This article explains the core components responsible for Solana’s speed.

1. Proof of History (PoH) – The Cryptographic Clock

Definition: PoH is a cryptographic timestamping mechanism, not a consensus mechanism. It provides a verifiable way to know the order of events without needing all validators to synchronize their clocks.This way we can have a centralized ordering mechanism followed by everyone.

Analogy: Imagine a drum beating “boom… boom… boom” repeatedly. Every transaction is tagged to a drum beat, giving a shared timeline of actions.
Everyone hearing the beat gets to know the ordering of transaction beat-wise.

Technical Function: PoH uses a hash chain (SHA-256) where each hash depends on the previous one. Transactions are inserted into this hash sequence to fix their order.

Benefit: Validators do not need to spend time agreeing on transaction order, reducing latency and enabling faster block creation.

2. Proof of Stake (PoS) – Leader Selection and Validation

Definition:Proof of Stake (PoS) decides who produces a block and who validates it. Validators lock up SOL tokens, and the more they stake, the higher their chance of being chosen as a leader.

who are validators ?
Validators are nodes (computers) that:

Produce new blocks when selected as leaders.
Validate blocks proposed by others.
Get rewarded for honest participation.
Risk losing their staked tokens if they cheat.

Analogy: Imagine referees in a game. One is chosen as the main referee (leader) to manage the match, while others check the referee’s decisions.

Technical Function:

Leaders produce blocks with ordered transactions.
Other validators vote on block validity using Tower BFT (Byzantine Fault Tolerance optimized with PoH).
Misbehaving leaders lose their stake.

together with PoH :

PoH orders transactions.
PoS ensures security.

Result → fast block production with trust.

3. How Solana Achieves Fast Transaction Speed

No Ordering Delays: PoH ensures transactions are already ordered.

Sealevel Runtime: Parallel Execution: Transactions declare which accounts they will read/write.Non-overlapping transactions are grouped into subsets and executed in parallel.

Hardware Utilization: Rust multithreading allows full use of CPU cores and GPUs.

Other Optimizations:

Gulf Stream: Forwards transactions to the future leader ahead of time.
Turbine: Breaks blocks into small packets for fast network propagation.
Pipeline: Optimized block validation across CPU cores.
Cloudbreak: High-performance storage structure for account data.

4. Subsets – The Core of Parallel Execution

Definition: A subset is a group of transactions that can be executed in parallel because they do not touch the same accounts.

Formation: Transactions are divided based on account overlap. Non-overlapping transactions →
same subset (parallel). Overlapping → different subset (sequential).
Example:
TX1 → (A, B), TX2 → (C), TX3 → (D, E), TX4 → (B, F)
Subset 1: TX1, TX2, TX3 (parallel)
Subset 2: TX4 (sequential)

Analogy: Like teams in different locations in a game fighting independently (parallel) or in the same
location (sequential).

so transactions in the same subsets are executed parallely in multiple cores of machine and each subset is executed sequentially, avoiding the problem where two transaction try to read/write to same account.

5. Comparison with Ethereum

Consensus
- Ethereum: PoW (before) / PoS (now)
- Solana: PoS + PoH
Transaction Ordering
- Ethereum: Validators choose from the mempool
- Solana: PoH cryptographically orders transactions
Execution
- Ethereum: Sequential (one transaction after another)
- Solana: Parallel execution via subsets (multiple transactions at once)
Block Time
- Ethereum: ~12 seconds
- Solana: ~400 milliseconds
Throughput
- Ethereum: ~15–30 TPS
- Solana: 3,000–5,000 TPS (theoretical limit of 65,000+)
MEV (Maximal Extractable Value)
- Ethereum: High (validators reorder transactions for profit)
- Solana: Minimal (transactions already pre-ordered by PoH)
Hardware Usage
- Ethereum: Limited hardware utilization
- Solana: Full use of multi-core CPUs and GPUs

6. Summary – Why Solana is So Fast
PoH: Orders transactions cryptographically.
PoS: Efficient block production and validation.
Subsets + Sealevel: Parallel execution of non-overlapping transactions.
Rust Multithreading & Hardware: Full utilization of CPU/GPU cores.
Network & Block Optimizations: Reduce latency.

So, that’s what makes Solana blazing fast and adaptive compared to giants like Ethereum.

Want me to break down more of Solana’s architecture? Drop a comment below 👇

Happy Weekend, folks 🚀✨

Building a Scalable Monorepo with TurboRepo

Anurag Bagri — Tue, 07 Jan 2025 19:50:43 +0000

Building a Scalable Monorepo with TurboRepo

Hey devs! 👋 Let’s talk about monorepos – not a fancy dinosaur species but a dev game-changer! If you’re juggling multiple repos for microservices or frontend apps, you know the chaos: updating dependencies, syncing changes, and managing tools. Enter TurboRepo to save the day. 🚀

Here’s what we’ll cover:

What a monorepo is (in plain English).
The magic of TurboRepo.
How to set up your scalable monorepo with TurboRepo.
Quick tips for smooth sailing.

let’s dive in!

What the Heck is a Monorepo? 🤔

A monorepo (short for "monolithic repository") is just a single repo that contains all your project folders. Think of it like a big filing cabinet with neat sections for your:

🖥️ Frontend apps (React, Next.js)
🔧 Backend services (Node.js, Express)
🛠️ Shared libraries (like UI components or utilities)

Why Monorepos Rock:

Centralized Dependencies: Update shared packages in one place. 🕵️‍♂️
Code Reuse: Share and reuse components easily.
Unified Tooling: Consistent linting, testing, and CI pipelines.
Simplified Collaboration: Everyone works from one repo – no confusion.

But managing a monorepo without help can be messy. That’s where TurboRepo comes in. 💪

Build System vs. Build Orchestrator vs. Monorepo Framework 🤓

Let’s break it down:

Build System: Compiles code (e.g., Webpack, Parcel).
Build Orchestrator: Manages multiple build tasks efficiently (TurboRepo fits here!).
Monorepo Framework: Offers tools for managing monorepos (like Nx).

So, What’s TurboRepo?

TurboRepo is a build orchestrator, not a full monorepo framework. It doesn’t replace tools like pnpm or Yarn workspaces but makes workflows faster with caching and parallel builds. 🚀

Why TurboRepo is Awesome 🦸‍♂️

Here’s why we love TurboRepo:

⚡ Blazing Fast Builds: Caches tasks intelligently.
🔄 Parallel Execution: Runs tasks simultaneously.
🔧 Incremental Builds: Only rebuilds what changed.
🤝 Seamless Integration: Works great with Next.js, TypeScript, and more.

Setting Up TurboRepo-Powered Monorepo 💻

Step 1: Install TurboRepo

First, ensure Node.js is installed. Then, install TurboRepo globally:

npm install -g turbo

Step 2: Initialize Your Monorepo

Create a folder for your monorepo:

mkdir my-monorepo
cd my-monorepo

Initialize with a package.json:

npm init -y

Add a turbo.json file:

npx turbo init

Your turbo.json might look like this:

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    }
  }
}

Step 3: Organize Your Projects

Create a packages/ folder for apps and libraries:

mkdir -p packages/frontend packages/backend packages/shared

Each project gets its own package.json and scripts. Example:

packages/frontend/package.json:

{
  "name": "frontend",
  "scripts": {
    "build": "next build"
  }
}

packages/backend/package.json:

{
  "name": "backend",
  "scripts": {
    "build": "tsc"
  }
}

Step 4: Link Dependencies

Use pnpm or Yarn workspaces to link dependencies. For pnpm:

pnpm init

Update your root package.json:

{
  "private": true,
  "workspaces": ["packages/*"]
}

Step 5: Run TurboRepo

Build all projects with one command:

turbo run build

TurboRepo orchestrates everything. 🎉

Pro Tips for Monorepo Bliss

🧹 Set Up Linting and Prettier: Keep your code consistent.
⚙️ Automate CI/CD: Use GitHub Actions or similar.
💾 Leverage Caching: TurboRepo’s caching saves time.
📜 Document Your Setup: A solid README helps a lot.

Wrapping Up

Monorepos are a fantastic way to scale projects, and TurboRepo makes managing them fast and efficient. Whether you’re a solo dev or part of a team, TurboRepo simplifies your workflow and saves you hours of build time.

Got questions or tips about monorepos? Drop them in the comments or hit me up on Twitter. Happy coding! 🚀

Bitcoin vs Ethereum vs Solana: Trendsetters in the Web3 Revolution ✨⚛✨

Anurag Bagri — Sun, 29 Dec 2024 19:43:05 +0000

The blockchain revolution began with Bitcoin, grew with Ethereum, and evolved further with Solana. These three blockchains have shaped Web3 in unique ways, each contributing distinct innovations that address the challenges of their predecessors. Let’s dive into how they emerged as trendsetters and compare their strengths and limitations. 🚀✨⚙ There are other blockchains as well but these three are like

Bitcoin: The Birth of Web3 ⛏⭐⚡

Bitcoin, introduced in 2009 by the pseudonymous Satoshi Nakamoto, is the pioneer of blockchain technology. Its primary offering was decentralized digital currency designed to eliminate intermediaries like banks in financial transactions.

Key Features:

💡 Decentralization: Peer-to-peer transactions without intermediaries.

💎 Digital Gold: Limited supply (21 million BTC) ensuring scarcity.

🔒 Security: Robust and highly secure due to its PoW mechanism(talk for future).

Shortcomings:

🐢 Scalability Issues: Bitcoin’s network can process only ~7 transactions per second (TPS).

⚡ Energy Intensive: High energy consumption due to PoW mining.

🎯 Limited Use Cases: Primarily focused on being a store of value and medium of exchange.

breakthrough... guys

Ethereum: Innovating Beyond Bitcoin 🔨⚛🌐

In 2015, Ethereum entered the scene, addressing Bitcoin’s shortcomings and introducing revolutionary concepts. Ethereum’s most significant innovation was the introduction of smart contracts, enabling programmable transactions and the creation of decentralized applications(dApps).✨⚖✨
This blockchain laid the foundation of the concept that there is more in web3 world other then cryptos..

Key Features:

🤖 Smart Contracts: Self-executing programs(contracts) that automate and decentralize processes. Consider a contract that lets user access there cryptos....

🌐 Decentralized Applications (dApps): Platforms for DeFi, NFTs, DAOs, and more.(prime objective of using a blockchain)

🌟 Vibrant Ecosystem: Large developer community driving innovation.

(nothing is perfect)
Shortcomings:

🚦 Scalability Challenges: Ethereum’s PoW mechanism limits TPS (~30).

💸 High Gas Fees: Network congestion leads to expensive transaction costs.

🔄 Transitioning Network: Moving to Ethereum 2.0 is still a work in progress.

here comes the lvl-999 :
Solana: The High-Performance Blockchain 🔥⚜🚀

Solana, launched in 2020, took a different approach to scalability and speed, solving many of the issues faced by Bitcoin and Ethereum. Solana achieved significantly higher performance and affordability. ✨🌟🚀

Key Features:

🚀 High Scalability: Processes up to 65,000 TPS.

💰 Low Transaction Costs: Minimal fees compared to Ethereum.

👨‍💻 Developer-Friendly: Optimized for fast dApp development.

Shortcomings:

⚖️ Decentralization Concerns: Relatively fewer validators raise questions about centralization.

⚙️ Network Stability: Occasional outages affect reliability.

🌱 Ecosystem Maturity: Smaller developer base compared to Ethereum.

Conclusion 🌐⭐📢

Each blockchain has played a pivotal role in the evolution of Web3:

🌟 Bitcoin established the foundation of decentralized finance.

🔨 Ethereum expanded blockchain’s capabilities with smart contracts and dApps.

🚀 Solana pushed the boundaries of speed and scalability, making blockchain accessible to more users.

long post...hmm. will try to write short posts from next time. Also if you guys want me to write on advanced web dev topics... please comment

what the heck is web3

Anurag Bagri — Mon, 07 Oct 2024 19:54:18 +0000

The internet is constantly evolving, and the term "Web3" is becoming the talk of the town. But what exactly does it mean, and why should someone care? To truly understand Web3, it helps to look at how we got here—starting from Web2, where most of us are currently.

What is Web2?

In Web2, the current internet, data is stored on centralized servers controlled by big companies like Google and Instagram. These platforms control our data and monetize it. For example, Instagram owns the photos you post, and Google profits from the data it collects about you.

This centralized model works but comes with downsides like privacy issues and lack of user control.

What is Blockchain?

The foundation of Web3 is blockchain technology. A blockchain is a distributed ledger that records data across a network of computers, rather than on a central server. It’s secure, transparent, and decentralized, meaning no single entity controls the data. This technology allows Web3 to function without a central authority.

Decentralization and Web3

In Web3, decentralization means that apps (called dApps) aren’t controlled by a company. Instead, data is shared across a network. Users have more control over their data, and ownership is distributed through tokens, which can give users governance rights in the platform. Unlike Web2, no single company owns or profits from your data.

Famous Blockchains

Key blockchains in the Web3 space include:

Bitcoin: The first blockchain, primarily for cryptocurrency.
Ethereum: Introduced smart contracts, enabling dApps and decentralized finance (DeFi).
Solana: Known for fast transactions and scalability, making it ideal for dApps and NFTs.
These blockchains have gone beyond cryptocurrency and are driving the Web3 revolution.

Web3 promises a future where users control their data and apps are decentralized, powered by blockchain technology. It’s still developing, but Web3 could fundamentally change how we interact with the internet.

i think this is fair enough for this post....
Guy's, let's keep this post short enough to not bore you! If you'd like a deeper dive into any of the topics mentioned, feel free to leave a comment below.