DEV Community: Himanshu Singh Tomar

Transformers Are Not Dead — But Hybrids Are the Future. Here's Why.

Himanshu Singh Tomar — Mon, 23 Mar 2026 06:17:55 +0000

I've been spending a lot of time recently understanding how the next generation of AI models are being built. Not just using them — actually understanding what's happening under the hood.

And here's what I've realized: the Transformer isn't going anywhere. But it's also not enough on its own anymore.

Let me explain.

The Problem Nobody Talks About

Every major LLM today — GPT-4, Claude, Gemini, Llama — is built on the Transformer architecture. It works. It works incredibly well. But it has one fundamental problem that gets worse as we push for longer contexts:

Self-attention is O(L²).

That means if you double your context window from 64K to 128K tokens, the compute doesn't just double — it quadruples. And the KV cache (the memory that stores past token information during inference) grows linearly with sequence length.

At 128K context with a 32-layer Transformer, you're looking at roughly 128 GB of KV cache. That's not fitting on a single GPU.

This is where Mamba enters the picture. And this is where things get interesting.

Part 1: The Transformer — What You Already Use

Let me break down what's actually happening inside a Transformer. If you've used any modern LLM, this is the engine running underneath.

The Full Architecture

The original Transformer (Vaswani et al., 2017 — "Attention Is All You Need") has two halves — an Encoder and a Decoder:

Most modern LLMs (GPT, Llama, Claude) use decoder-only Transformers — they drop the encoder entirely and just stack decoder layers. But the core mechanism is the same.

How Self-Attention Actually Works

This is the heart of the Transformer. Let me walk through it with a concrete example.

Say you have the sentence: "The cat sat on it"

When the model processes the token "it", it needs to figure out: what does "it" refer to?

Step 1: Each token creates three vectors from its embedding:

Query (Q) — "What am I looking for?"
Key (K) — "What do I contain?"
Value (V) — "What information do I carry?"

Step 2: Compute attention scores = dot product of Q("it") with K(every other token):

flowchart LR
    T1["The = 0.05"]
    T2["cat = 0.72"]
    T3["sat = 0.12"]
    T4["on = 0.03"]
    T5["it = 0.08"]

    classDef low fill:#f1f5f9,stroke:#94a3b8,color:#334155
    classDef high fill:#c084fc,stroke:#9333ea,stroke-width:3px,color:#3b0764

    class T1,T3,T4,T5 low
    class T2 high

Step 3: Softmax normalizes scores into attention weights (sum = 1.0)

Step 4: Output = weighted sum of all Value vectors

The result? "it" attends most strongly to "cat" (weight 0.72) — it learned that "it" refers to "the cat" without anyone telling it to. That's the magic.

Multi-Head Attention

The model runs this process multiple times in parallel (typically 8-16 heads). Each head learns different relationships:

The Feed-Forward Network

After attention, each token goes through a two-layer MLP independently:

FFN(x) = max(0, x·W₁ + b₁)·W₂ + b₂

This is where the model stores factual knowledge — it acts like a key-value memory. Research has shown you can actually locate specific facts in specific neurons of the FFN layers.

Residual Connections + Layer Norm

Every sub-layer is wrapped with: LayerNorm(x + SubLayer(x))

This prevents gradient degradation through deep stacks. Without residuals, gradients would vanish by layer 10. With them, you can stack 80+ layers.

The Cost

Operation	Training Cost	Inference (per token)	Memory
Self-Attention	O(L²·d)	O(L·d)	O(L·d) KV cache
FFN	O(L·d²)	O(d²)	O(d²) weights

That L² in attention is the killer. Everything else scales linearly.

Part 2: Mamba — The Challenger

Mamba was introduced by Albert Gu and Tri Dao in December 2023. It takes a completely different approach: instead of letting every token look at every other token, it processes the sequence through a Selective State Space Model (SSM).

The Core Idea: A Learned Compression

Think of it like this:

Transformer: keeps a complete photo album of every past token (KV cache)
Mamba: keeps a single, constantly-updated summary note (hidden state)

The math comes from continuous dynamical systems:

Continuous form:
  h'(t) = A·h(t) + B·x(t)     ← hidden state evolution
  y(t)  = C·h(t)               ← output

Discretized (for actual tokens):
  h_t = A_bar · h_(t-1) + B_bar · x_t   ← update hidden state
  y_t = C · h_t                          ← read output

Where:

A (transition/decay matrix) — controls how much old state is retained
B (input matrix) — controls how much of the new token gets written in
C (output matrix) — controls what gets read out
Delta (step size) — controls discretization granularity

What Makes Mamba Different: Selectivity

Previous state space models (S4, H3) used fixed A, B, C parameters — same for every token. Mamba's key innovation: these parameters are input-dependent.

This is selectivity. The model dynamically decides, per-token:

When to remember (small Delta = gentle update)
When to forget (large Delta = aggressive reset)
What to write (B controls input projection)
What to output (C controls readout)

A delimiter token might trigger high forgetting. A content word triggers careful accumulation. The model learns this entirely from data.

The Mamba Block

flowchart TB
    INPUT["Input - B, L, D"] --> NORM["RMS Norm"]
    NORM --> LP1["Branch A: Linear Proj D to E"]
    NORM --> LP2["Branch B: Linear Proj D to E - gate"]

    LP1 --> CONV["Causal Conv1D kernel=4"]
    CONV --> SILU1["SiLU Activation"]
    SILU1 --> SSSM["SELECTIVE SSM - Input-dependent A, B, C, Delta"]

    LP2 --> SILU2["SiLU Activation"]

    SSSM --> MUL["Multiply - Gating"]
    SILU2 --> MUL

    MUL --> LP3["Linear Proj E to D"]
    LP3 --> RES["Residual Add"]
    INPUT -.->|"Skip connection"| RES
    RES --> OUT["Output - B, L, D"]

    classDef neutral fill:#f1f5f9,stroke:#64748b,color:#1e293b
    classDef norm fill:#e2e8f0,stroke:#64748b,color:#1e293b
    classDef proj fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    classDef conv fill:#fed7aa,stroke:#f97316,stroke-width:2px,color:#7c2d12
    classDef ssm fill:#fecaca,stroke:#ef4444,stroke-width:3px,color:#7f1d1d
    classDef gate fill:#fce7f3,stroke:#ec4899,stroke-width:2px,color:#831843
    classDef res fill:#d1fae5,stroke:#10b981,color:#064e3b

    class INPUT,OUT neutral
    class NORM,SILU1,SILU2 norm
    class LP1,LP2,LP3 proj
    class CONV conv
    class SSSM ssm
    class MUL gate
    class RES res

The split-branch design is key: one path does the heavy computation (Conv1D followed by SSM), the other acts as a gate. Multiplying them together gives the model fine control over information flow.

The Hardware Trick: Parallel Scan

"But wait," you're thinking, "if Mamba processes tokens sequentially through a recurrence, isn't training slow?"

Here's the engineering brilliance: the state update is associative. That means you can parallelize it using a scan (prefix sum) operation — the same algorithm GPUs are incredibly good at.

During training, Mamba achieves near-Transformer parallelism. During inference, it's purely recurrent — just update the hidden state with each new token. No KV cache. Constant memory. Constant time per token.

The Hidden State Flow

flowchart LR
    X1["x1"] -->|"B"| H1["h1"]
    X2["x2"] -->|"B"| H2["h2"]
    X3["x3"] -->|"B"| H3["h3"]
    X4["x4"] -->|"B"| H4["h4"]
    X5["x5"] -->|"B"| H5["h5"]

    H1 -->|"A decay"| H2
    H2 -->|"A decay"| H3
    H3 -->|"A decay"| H4
    H4 -->|"A decay"| H5

    H1 -->|"C"| Y1["y1"]
    H2 -->|"C"| Y2["y2"]
    H3 -->|"C"| Y3["y3"]
    H4 -->|"C"| Y4["y4"]
    H5 -->|"C"| Y5["y5"]

    classDef inp fill:#fef3c7,stroke:#f59e0b,color:#78350f
    classDef hid fill:#ccfbf1,stroke:#14b8a6,stroke-width:2px,color:#134e4a
    classDef outp fill:#e0e7ff,stroke:#6366f1,color:#312e81

    class X1,X2,X3,X4,X5 inp
    class H1,H2,H3,H4,H5 hid
    class Y1,Y2,Y3,Y4,Y5 outp

Each hidden state h_t carries a compressed summary of all past tokens. The A matrix controls decay (how much old info fades), B controls what gets written in, C controls what gets read out. All input-dependent in Mamba.

The Cost

Operation	Training Cost	Inference (per token)	Memory
Selective SSM	O(L·d) linear	O(d) constant	O(N·d) fixed state
Conv1D	O(L·d)	O(d)	O(k·d) kernel

Everything is linear or constant. No quadratic anywhere.

Part 3: The Head-to-Head Comparison

Let me be real about where each architecture wins and loses:

Dimension	Transformer	Mamba
Core mechanism	Self-attention (token-to-token)	Selective SSM (compressed state)
Training compute	O(L²·d) quadratic	O(L·d) linear
Inference per token	O(L·d) grows with context	O(d) constant
Memory (KV cache)	O(L·d) grows	O(N·d) fixed
Context window	Fixed (4K-128K) hard wall	Theoretically unlimited
Exact retrieval	Perfect — can pinpoint any token	Lossy — compressed into finite state
In-context learning	Strong — dynamic pattern routing	Weaker on exact copy/retrieval
Scale proven	400B+ parameters	Up to ~8B so far
Ecosystem	Mature (FlashAttention, vLLM)	Newer, custom CUDA kernels

The Fundamental Tradeoff

It comes down to this:

Attention = complete, addressable memory of every past token. You pay O(L²) for it.

SSM = fixed-size compressed summary of history. Much cheaper, but lossy.

The question is: is that compression sufficient for the task at hand?

For most of the computation in a forward pass — yes. You don't need to look at every single past token to process the word "the". But for some critical operations — resolving coreferences, copying exact numbers, following specific instructions — you need the precision of attention.

And that's exactly why hybrids are the answer.

Part 4: The Hybrid Architecture — Best of Both Worlds

This is where I got really excited. The hybrid approach isn't a compromise — it's genuinely better than either architecture alone.

The Core Insight

You don't need quadratic attention at every single layer.

Most layers are doing local, incremental processing. Mamba handles this beautifully at linear cost. But at certain critical points, you need the model to "check its work" against the full context with exact attention.

Jamba: The Reference Implementation

AI21 Labs built Jamba — the first production-scale hybrid (52B total / 12B active, 256K context). Here's the layer stack:

flowchart TB
    INPUT["Token Embedding"] --> M1

    subgraph BLOCK1["Layers 1-7 : Mamba Foundation"]
        M1["Mamba SSM + Dense FFN"]
        M2["Mamba SSM + Dense FFN"]
        M3["... x 7 layers total"]
    end

    M3 --> A1

    subgraph ATTN1["Layer 8 : Attention Checkpoint"]
        A1["Self-Attention + MoE FFN -- KV cache stored"]
    end

    A1 --> M4

    subgraph BLOCK2["Layers 9-15 : Mamba Efficient Flow"]
        M4["Mamba SSM + MoE FFN"]
        M5["Mamba SSM + MoE FFN"]
        M6["... x 7 layers total"]
    end

    M6 --> A2

    subgraph ATTN2["Layer 16 : Attention Checkpoint"]
        A2["Self-Attention + MoE FFN -- KV cache stored"]
    end

    A2 --> M7

    subgraph BLOCK3["Layers 17-23 : Mamba Efficient Flow"]
        M7["... x 7 Mamba SSM layers"]
    end

    M7 --> A3

    subgraph ATTN3["Layer 24 : Attention Checkpoint"]
        A3["Self-Attention + MoE FFN"]
    end

    A3 --> M8

    subgraph BLOCK4["Layers 25-31 : Mamba Efficient Flow"]
        M8["... x 7 Mamba SSM layers"]
    end

    M8 --> A4

    subgraph ATTN4["Layer 32 : Attention Checkpoint"]
        A4["Self-Attention + MoE FFN"]
    end

    A4 --> NORM["RMS Norm + Linear Head"]
    NORM --> OUTPUT["Output Logits"]

    classDef mambaBlock fill:#d1fae5,stroke:#10b981,stroke-width:2px,color:#064e3b
    classDef attnBlock fill:#ede9fe,stroke:#8b5cf6,stroke-width:2px,color:#3b1f7e
    classDef mambaNode fill:#a7f3d0,stroke:#059669,color:#064e3b
    classDef attnNode fill:#c4b5fd,stroke:#7c3aed,color:#3b1f7e
    classDef ioNode fill:#fef3c7,stroke:#f59e0b,color:#78350f
    classDef normNode fill:#e2e8f0,stroke:#64748b,color:#1e293b

    class BLOCK1,BLOCK2,BLOCK3,BLOCK4 mambaBlock
    class ATTN1,ATTN2,ATTN3,ATTN4 attnBlock
    class M1,M2,M3,M4,M5,M6,M7,M8 mambaNode
    class A1,A2,A3,A4 attnNode
    class INPUT,OUTPUT ioNode
    class NORM normNode

Pattern: 7 Mamba layers followed by 1 Attention layer, repeat. That's 87.5% Mamba, 12.5% Attention.

Why This Pattern Works

Mamba layers (87.5% of the stack) handle:

Local patterns and syntax
Sequential information flow
Building up contextual representations
General "thinking" that doesn't need exact retrieval

Attention layers (12.5% of the stack) handle:

Disambiguating words ("bank" = river bank or financial bank?)
Coreference resolution ("it" → "the cat")
Exact information retrieval from context
Following specific instructions from the prompt

The Mamba layers enrich the token representations before they hit the attention layer. By the time attention fires, the representations are already pretty good — attention just needs to do targeted cleanup and retrieval.

The MoE Layer: The Third Ingredient

Jamba also uses Mixture of Experts (MoE) in its feed-forward layers:

flowchart TD
    TOKEN["Input Token"] --> ROUTER["Router Network - scores all 16 experts"]
    ROUTER -->|"Selected"| E3["Expert 3 - active"]
    ROUTER -->|"Selected"| E11["Expert 11 - active"]
    ROUTER -.->|"Not selected"| E1["Expert 1"]
    ROUTER -.->|"Not selected"| E2["Expert 2"]
    ROUTER -.->|"..."| E16["Expert 16"]
    E3 --> SUM["Weighted Sum"]
    E11 --> SUM
    SUM --> OUT["Output"]

    classDef token fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,color:#78350f
    classDef router fill:#fecaca,stroke:#ef4444,stroke-width:2px,color:#7f1d1d
    classDef active fill:#bbf7d0,stroke:#22c55e,stroke-width:2px,color:#14532d
    classDef inactive fill:#f1f5f9,stroke:#cbd5e1,color:#94a3b8
    classDef sum fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    classDef neutral fill:#f1f5f9,stroke:#64748b,color:#1e293b

    class TOKEN token
    class ROUTER router
    class E3,E11 active
    class E1,E2,E16 inactive
    class SUM sum
    class OUT neutral

16 experts total, 2 active per token. This means:

Total parameters: 52B (lots of knowledge capacity)
Active parameters per token: 12B (fast inference)
Each expert can specialize (math, code, language, reasoning, etc.)

The Memory Savings Are Massive

flowchart LR
    subgraph TRANSFORMER["Pure Transformer - 32 layers"]
        T1["32 attention layers | 32 KV caches | ~128 GB at 256K | Needs multiple GPUs"]
    end

    subgraph HYBRID["Jamba Hybrid - 32 layers"]
        H1["4 attn + 28 Mamba | 4 KV caches | ~16 GB at 256K | Single 80GB GPU"]
    end

    TRANSFORMER -->|"8x memory reduction"| HYBRID

    classDef bad fill:#fecaca,stroke:#ef4444,stroke-width:2px,color:#7f1d1d
    classDef good fill:#bbf7d0,stroke:#22c55e,stroke-width:2px,color:#14532d
    classDef badNode fill:#fee2e2,stroke:#ef4444,color:#7f1d1d
    classDef goodNode fill:#dcfce7,stroke:#22c55e,color:#14532d

    class TRANSFORMER bad
    class HYBRID good
    class T1 badNode
    class H1 goodNode

That's the difference between needing a cluster and fitting on a single GPU.

Part 5: How Data Flows Through a Hybrid

Let me trace what happens when you send "The bank of the river was steep and muddy" through a hybrid model:

Phase 1: Mamba Layers Build Compressed Context

flowchart LR
    H1["h: the bank..."] -->|"A decay"| H2["h: bank of river..."]
    H2 -->|"A decay"| H3["h: river was steep..."]
    H3 -->|"A decay"| H4["h: steep and..."]

    classDef s1 fill:#a7f3d0,stroke:#059669,color:#064e3b
    classDef s2 fill:#6ee7b7,stroke:#059669,color:#064e3b
    classDef s3 fill:#34d399,stroke:#059669,color:#064e3b
    classDef s4 fill:#10b981,stroke:#047857,color:#f0fdf4

    class H1 s1
    class H2 s2
    class H3 s3
    class H4 s4

Good at: local patterns, syntax, general context. Weak at: pinpointing a specific distant token.

Phase 2: Attention Layer Resolves Ambiguities

flowchart TD
    AND["and - query token"] -->|"weight: 0.35"| STEEP["steep"]
    AND -->|"weight: 0.28"| RIVER["river"]
    AND -->|"weight: 0.22"| BANK["bank"]
    AND -->|"weight: 0.08"| WAS["was"]

    BANK2["bank - query"] -->|"weight: 0.65 STRONG"| RIVER2["river - disambiguates!"]
    BANK2 -->|"weight: 0.12"| OF["of"]
    BANK2 -->|"weight: 0.10"| THE["the"]

    classDef query fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,color:#78350f
    classDef high fill:#c4b5fd,stroke:#8b5cf6,color:#3b1f7e
    classDef mid fill:#93c5fd,stroke:#3b82f6,color:#1e3a5f
    classDef low fill:#f1f5f9,stroke:#94a3b8,color:#334155
    classDef match fill:#fecaca,stroke:#ef4444,stroke-width:3px,color:#7f1d1d

    class AND,BANK2 query
    class STEEP high
    class RIVER,BANK mid
    class WAS,OF,THE low
    class RIVER2 match

This is the checkpoint moment. "bank" attends to "river" with weight 0.65 — it gets disambiguated as "river bank", not "financial bank". After this layer, the representation is precise.

Phase 3-4: More Mamba → More Attention → Repeat

Back to efficient Mamba processing, now with enriched representations. The disambiguation carries forward. Next attention checkpoint does higher-level reasoning.

Part 6: The Three Design Decisions

If you're building or fine-tuning a hybrid model, these are the knobs:

1. Attention-to-Mamba Ratio

flowchart LR
    TOO_MUCH["Too much attention - back to Transformer costs"] --- SWEET["Sweet spot 1:6 to 1:8 - best tradeoff"] --- TOO_LITTLE["Too little attention - retrieval quality drops"]

    classDef bad fill:#fecaca,stroke:#ef4444,color:#7f1d1d
    classDef good fill:#bbf7d0,stroke:#22c55e,stroke-width:2px,color:#14532d

    class TOO_MUCH,TOO_LITTLE bad
    class SWEET good

2. Where to Place Attention Layers

Early layers learn low-level features (syntax, local patterns) → Mamba handles fine
Deep layers handle abstract reasoning, long-range deps → attention more valuable
Jamba distributes evenly (every 8th layer)

3. MoE vs Dense FFN

First few layers: Dense FFN (shared features needed by all tokens)
Later layers: MoE (specialized knowledge, different tokens need different experts)

Part 7: Other Hybrid Models to Watch

Jamba isn't alone. The hybrid approach is becoming a movement:

Model	Approach	Key Innovation
Jamba (AI21)	Mamba + Attention + MoE	First production hybrid, 256K context
Zamba (Zyphra)	Mamba + shared attention	Shared KV cache across attention insertion points
Griffin (DeepMind)	Gated linear recurrence + attention	Google's take on efficient recurrence
RWKV-6	Linear attention + recurrence	Open-source, Transformer-quality at linear cost
Mamba-2 (Gu & Dao)	Improved SSM as structured matrix mult	Faster hardware utilization, easier hybridization

Part 8: The Future — My Take

Here's what I think is going to happen in the next 1-2 years:

Transformers Are NOT Dead

Let me be clear. Transformers won't die. They're:

Proven at 400B+ parameter scale
Backed by massive ecosystem (FlashAttention, vLLM, TensorRT, ONNX)
Still the best at tasks requiring precise information routing
The architecture behind every frontier model today

You can't just throw away 7+ years of engineering and optimization. The tooling, the infrastructure, the deployment pipelines — all built for Transformers.

But Pure Transformers Are Over-Engineered

Here's the thing: most of the computation in a Transformer is wasted. Not every layer needs quadratic attention. Not every token needs to look at every other token at every layer.

The research is converging on a clear signal: use the minimum attention necessary, fill the rest with efficient recurrence.

Hybrids Are the Path Forward

flowchart TD
    F1["Frontier labs adopt hybrids -- 8x memory savings too compelling"]
    F2["Attention becomes premium -- used sparingly like DB indexes"]
    F3["Open-source hybrids close the gap -- Mamba + RWKV already open"]
    F4["1M+ context windows standard -- constant-memory inference"]
    F5["New hardware optimizations -- custom silicon for selective scan"]
    F6["Cost per token drops -- model tiering strategies evolve"]

    classDef c1 fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    classDef c2 fill:#e0e7ff,stroke:#6366f1,color:#312e81
    classDef c3 fill:#d1fae5,stroke:#10b981,color:#064e3b
    classDef c4 fill:#fef3c7,stroke:#f59e0b,color:#78350f
    classDef c5 fill:#fce7f3,stroke:#ec4899,color:#831843
    classDef c6 fill:#ccfbf1,stroke:#14b8a6,color:#134e4a

    class F1 c1
    class F2 c2
    class F3 c3
    class F4 c4
    class F5 c5
    class F6 c6

For Us Developers

The architectural shift means real changes in how we build:

Cost per token will drop — hybrid models need less compute
Context windows will explode — entire codebases in context becomes feasible
Real-time apps become easier — Mamba's O(1) inference enables streaming use cases
Model tiering evolves — hybrid for bulk processing, Transformer for precision

Wrapping Up

The AI architecture landscape is evolving fast. Transformers gave us the foundation. Mamba showed us there's a better way to handle long sequences. And hybrids are proving you don't have to choose — you can have both.

The future isn't "Transformer vs Mamba." It's "Transformer AND Mamba, used where each excels."

If you're an engineer working with AI, now is a great time to understand these architectures. The next generation of models you'll be using — and maybe building on — will likely be hybrids.

If you found this useful, drop a like or a comment. I'm happy to go deeper on any section — the attention math, the SSM discretization, or the MoE routing if there's interest.

I'm Himanshu — an AI-augmented full-stack developer exploring how these architectures change the way we build software. Follow me for more deep dives on AI engineering.

Have You Wondered How Websites Show the Download Button According to Your Operating System?

Himanshu Singh Tomar — Mon, 06 Oct 2025 18:30:31 +0000

Like when you visit a website, and it already knows you’re on Windows or macOS — magic, right?
Let’s decode that small but clever trick together.

💭 The Curiosity

A few days ago, while visiting popular websites like VS Code, Zoom, or Slack, I noticed something fascinating.
Every time I opened them, the download button automatically matched my OS —
“Download for macOS” on my Mac, and “Download for Windows” when I switched to my PC.

That made me wonder — how does a website even know what operating system I’m using?

⚙️ The Hidden Magic Behind It

Turns out, your browser quietly sends a small piece of information called a User Agent every time you open a website.
It’s like a self-introduction that tells the website who you are and what device you’re on.

Something like this:

“Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0 Safari/537.36”

From that single line, the website can identify if you’re on Windows, macOS, Linux, or even Android/iOS.

Once it knows that, it can personalize what you see:

Show the right download button for your OS
Change the UI elements or icons
Load platform-specific instructions

🌍 Where You’ve Seen It

This isn’t just a small trick — it’s used by almost every major platform you visit:

Zoom, Discord, and Slack: Show OS-based download buttons.
Spotify and VS Code: Automatically serve installers that match your operating system.
Web apps: Adjust UI layouts based on your device type or platform.

These small adjustments make users feel like the site was built just for them.

💬 My Thought

Imagine this — someone opens your website from a Windows laptop and sees a calm, blue Windows-inspired background.
Another person opens it on a Mac and sees a sleek, minimalist macOS-style wallpaper.
And maybe someone on Linux gets a bold, terminal-themed design.

How cool does that sound? 😄
Just by detecting the OS, your website starts to feel more personal — like it actually knows its visitors.

Scalable React Application Architecture Guide

Himanshu Singh Tomar — Wed, 02 Jul 2025 07:11:59 +0000

🧩 1. Project Structure & Organizing Code

Feature-based directory layout:


src/
├── features/         # Feature-specific logic
├── components/       # Reusable presentational components
├── hooks/            # Custom hooks
├── services/         # API clients and side-effects
├── store/            # Global state (Redux/Zustand/Recoil)
├── utils/            # Pure utility functions
└── App.tsx / index.tsx

Barrel exports: Use index.ts files inside folders to group and simplify imports.

🛠 2. Design Patterns & Component Architecture

Container vs Presentational Components:
Container: Handles state, API calls.
Presentational: Stateless UI component, receives props.
Hooks & Custom Hooks:
Shared logic should go into custom hooks like useAuth, useForm, useFetch.
Higher-Order Components (HOC):
For reusable behaviors (e.g., logging, auth gating).
Compound Components & Context:
Enable scoped, flexible UIs using parent-child coordination.
Memoization:
Use React.memo, useMemo, useCallback for performance.

🎯 3. State & Data Management

Global state management:
Use Redux Toolkit, Recoil, Zustand, or Context API.
Minimize global state. Keep UI-specific state local.
Unidirectional data flow:
Actions → Reducers → State → Props → UI
Side-effect management:
Use Redux Thunk, Redux Saga, React Query, or SWR for async ops.

📡 4. API Layer & Services

Service abstraction:
Encapsulate all API calls in /services using Axios/Fetch.
Example:
ts export const getUserProfile = () => api.get('/user/profile');
Error & loading handling:
Use React Query or loading/error state wrappers.
Authentication tokens:
Prefer HttpOnly cookies for secure auth.
Abstract auth/session logic in dedicated services or hooks.

🧪 5. Code Quality & Testing

Linting:
Use ESLint, Prettier, and Husky for commit-time lint checks.
Testing:
Unit tests: Vitest/Jest + React Testing Library
Integration/E2E: Playwright or Cypress
Testing strategy:
Write tests for:
- Pure functions (utils, services)
- Component rendering + behavior
- Hooks logic
- API handling

🚀 6. Performance Optimization

Code splitting:
Lazy load route-based components using React.lazy() and Suspense.
Memoization:
Prevent re-renders with React.memo, useMemo, and useCallback.
Bundle analysis:
Use tools like webpack-bundle-analyzer or Vite plugins.
Avoid over-rendering:
Lift state only when necessary.
Split complex components.

🔐 7. Security & Error Handling

Error boundaries:
Use ErrorBoundary components to catch rendering issues.
Global error handling:
Wrap API services to catch and standardize error handling.
Security practices:
Validate all inputs.
Avoid XSS via sanitization.
Use secure cookies and SameSite attributes.

🛡️ 8. Bulletproof React Template (by alan2207)

Repo: github.com/alan2207/bulletproof-react

Feature-first folder structure
Modular state management (Redux Toolkit or Zustand)
Centralized API abstraction
Forms (React Hook Form + Zod)
Routes split per feature
Testing setup with Vitest, Testing Library, Playwright
Styling with Tailwind/Shadcn UI
Environment validation (Zod)
Vite-based build pipeline

🧭 Sample Folder Structure


src/
├── features/
│   └── auth/
│       ├── components/
│       ├── hooks/
│       ├── api/
│       └── AuthPage.tsx
├── components/
├── services/
├── hooks/
├── store/
├── routes/
├── utils/
├── App.tsx
└── main.tsx

✅ Final Checklist for Scalable React Apps

[x] Feature-based directory structure
[x] Clear separation of concerns (logic vs UI)
[x] Abstracted services and state
[x] Custom hooks for shared logic
[x] Error boundaries and global error handling
[x] API and state decoupling
[x] Secure token storage practices
[x] CI-ready with linting, formatting, and testing

📚 References

EC2 Placement Groups: Optimizing Instance Placement for Performance and Availability

Himanshu Singh Tomar — Tue, 06 May 2025 19:12:26 +0000

Placement groups in Amazon EC2 allow you to influence how your instances are positioned relative to each other in the underlying AWS infrastructure. By strategically organizing your instances, you can optimize your applications for specific workload requirements such as high network throughput, low latency, or high availability.

What are EC2 Placement Groups?

A placement group is a logical grouping of EC2 instances that influences how these instances are placed on the underlying hardware infrastructure. Placement groups help you meet specific performance, availability, or failure tolerance requirements by controlling how instances are distributed across different hardware.

Types of Placement Groups

AWS offers three distinct placement group strategies, each designed for different use cases:

1. Cluster Placement Groups

Cluster placement groups pack instances close together inside an Availability Zone, providing the lowest-latency network performance possible between instances.

Key characteristics:

Instances are placed in the same high-bisection bandwidth segment of the network
Provides the lowest latency and highest packet-per-second network performance
All instances are placed in a single Availability Zone
Limited to a single Availability Zone

Best for:

High Performance Computing (HPC) applications
Tightly-coupled node-to-node communication
Applications requiring extremely low-latency networking
Big data jobs requiring fast completion times

2. Spread Placement Groups

Spread placement groups strictly place instances on distinct underlying hardware to reduce correlated failures.

Key characteristics:

Each instance runs on different physical hardware
Maximum of 7 instances per Availability Zone in each spread placement group
Can span multiple Availability Zones in a region
Provides instance-level failure isolation

Best for:

Applications that require high availability
Critical applications where instances should be isolated from each other
Applications where failure of a single instance should not affect other instances
Small applications needing maximum reliability

3. Partition Placement Groups

Partition placement groups distribute instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions.

Key characteristics:

Divides each group into logical segments called partitions (up to 7 per AZ)
Each partition has its own set of racks with independent network and power
Can span multiple Availability Zones in a region
Hundreds of instances per placement group

Best for:

Large distributed and replicated workloads
HDFS, HBase, and Cassandra deployments
Applications deployed across multiple instances that need topology awareness
Applications that need to isolate potential hardware failures to a subset of the system

Placement Group Limitations and Rules

Understanding these limitations will help you plan your deployment effectively:

You can't merge placement groups
An instance can only be launched in one placement group at a time
Reserved Instances provide a capacity reservation for EC2 instances in a specific Availability Zone, but don't guarantee placement group capacity
On-Demand Capacity Reservation can be used with placement groups to reserve capacity
Existing instances cannot be moved into a placement group; you must create a new instance or snapshot an existing instance and launch a new one
Not all instance types are supported in all placement group types
AWS has a soft limit on the number of placement groups per region (default is 500)

When to Use Each Placement Group Type

Placement Group Type	Use When You Need	Avoid When
Cluster	Highest network performance, lowest latency	High availability across AZs is required
Spread	Maximum instance failure isolation	You need more than 7 instances per AZ
Partition	Balance between performance and partial fault tolerance	Complete instance isolation is required

Step-by-Step: Creating and Using Placement Groups

Creating a Placement Group

Using the AWS Management Console

Open the EC2 Console
- Sign in to the AWS Management Console
- Navigate to the EC2 dashboard
Access Placement Groups
- In the navigation pane, choose Placement Groups
- Click Create placement group
Configure the Placement Group
- Enter a name for your placement group
- Choose the placement strategy (Cluster, Spread, or Partition)
- For Partition placement groups, optionally specify the number of partitions
- Click Create group

Using the AWS CLI

# Create a cluster placement group
aws ec2 create-placement-group --group-name MyClusterGroup --strategy cluster

# Create a spread placement group
aws ec2 create-placement-group --group-name MySpreadGroup --strategy spread

# Create a partition placement group with 5 partitions
aws ec2 create-placement-group --group-name MyPartitionGroup --strategy partition --partition-count 5

Launching Instances in a Placement Group

Using the AWS Management Console

Start the Instance Launch Process
- Navigate to the EC2 dashboard
- Click Launch Instance
Select an AMI and Instance Type
- Choose an AMI
- Select an instance type compatible with placement groups
Configure Instance Details
- On the "Configure Instance" page, find the "Placement group" section
- Select "Add instance to placement group"
- Choose your placement group from the dropdown
- For partition placement groups, optionally select a specific partition
Complete the Launch Process
- Configure storage, security groups, and other settings as needed
- Review and launch your instance

Using the AWS CLI

# Launch an instance in a cluster placement group
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type c5.large \
  --placement "GroupName=MyClusterGroup" --count 1

# Launch an instance in a specific partition of a partition placement group
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type r5.large \
  --placement "GroupName=MyPartitionGroup,PartitionNumber=3" --count 1

# Launch an instance in a spread placement group
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type m5.large \
  --placement "GroupName=MySpreadGroup" --count 1

Viewing Your Placement Groups

Using the AWS Management Console

Navigate to the EC2 dashboard
In the navigation pane, choose Placement Groups
View your placement groups and their details

Using the AWS CLI

# List all placement groups
aws ec2 describe-placement-groups

# Get details about a specific placement group
aws ec2 describe-placement-groups --group-names MyClusterGroup

Deleting a Placement Group

Using the AWS Management Console

Navigate to the EC2 dashboard
In the navigation pane, choose Placement Groups
Select the placement group to delete
Choose Actions, then Delete placement group
Confirm the deletion

Using the AWS CLI

# First terminate all instances in the placement group, then delete it
aws ec2 delete-placement-group --group-name MyClusterGroup

Best Practices for EC2 Placement Groups

General Best Practices

Launch instances with a single request
- Launch all instances within a placement group in a single request to increase the likelihood of fulfilling the placement requirements
Use the same instance type
- Use the same instance type for all instances in a cluster placement group to ensure consistent network performance
Plan for capacity
- Reserve capacity in advance for placement groups, especially for cluster placement groups
Consider enhanced networking
- Use instances that support Enhanced Networking for better performance, especially in cluster placement groups

Cluster Placement Group Best Practices

Use a homogeneous instance fleet
- Launch the same instance type and size for optimal network performance
Launch all instances at once
- This maximizes the chances of getting the required capacity
Consider instance limits
- Be aware of your account's instance limits, as cluster placement groups can require substantial resources in a single AZ

Spread Placement Group Best Practices

Use for critical applications
- Deploy mission-critical applications where each instance must be isolated from failure of other instances
Combine with multiple AZs
- Spread across multiple AZs for maximum availability
Plan around the 7-instance limit
- Design your architecture to work within the 7-instance-per-AZ limitation

Partition Placement Group Best Practices

Use topology awareness
- Make your applications topology-aware to optimize communication between partitions
Balance workloads across partitions
- Distribute workloads evenly across partitions for optimal performance
Use partition information
- Applications can access partition information via instance metadata to make intelligent data replication decisions

Real-World Scenarios and Solutions

Scenario 1: High-Performance Computing Cluster

Requirement: Create a high-performance cluster for scientific computing with minimal network latency.

Solution:

Create a cluster placement group
Launch all compute nodes using the same high-performance instance type (e.g., c5n.18xlarge)
Use EFA-enabled instances for MPI workloads
Configure a single request to launch all instances simultaneously

Scenario 2: Highly Available Web Application

Requirement: Deploy a web application with maximum availability and failure isolation.

Solution:

Create a spread placement group spanning multiple AZs
Launch up to 7 instances per AZ in the spread placement group
Configure an Application Load Balancer to distribute traffic
Set up Auto Scaling with the placement group for automatic recovery

Scenario 3: Large Distributed Database

Requirement: Deploy a large distributed database system (like Apache Cassandra) with fault tolerance.

Solution:

Create a partition placement group with 5 partitions
Launch your database nodes across the partitions
Configure your database to be topology-aware
Ensure replication factors consider partition boundaries

Monitoring Placement Groups

AWS provides several tools to monitor the health and performance of your instances in placement groups:

CloudWatch Metrics
- Monitor network performance metrics to verify you're getting the expected benefits from your placement strategy
EC2 Status Checks
- Keep track of instance status checks to quickly identify hardware issues
AWS Trusted Advisor
- Get recommendations for optimizing your EC2 placement groups
AWS Health Dashboard
- Be alerted about potential hardware failures that might affect your placement groups

Conclusion

EC2 placement groups are a powerful tool for optimizing the placement of your instances to meet specific performance, availability, and fault tolerance requirements. By understanding the characteristics of each placement group type and following the best practices outlined in this guide, you can design EC2 deployments that better meet your application's unique requirements.

Whether you need the lowest-latency network performance for HPC workloads, maximum instance isolation for critical applications, or a balance between performance and fault tolerance for distributed systems, EC2 placement groups provide the controls you need to implement your ideal infrastructure architecture in AWS.

Remember that placement groups are a free feature of Amazon EC2, so there's no additional cost to using them—making them an essential tool in your AWS optimization toolkit.

Understanding ENI (Elastic Network Interface) in EC2

Himanshu Singh Tomar — Tue, 06 May 2025 18:31:57 +0000

Elastic Network Interfaces (ENIs) are a fundamental networking component in Amazon EC2 that provide enhanced connectivity, security, and flexibility for your cloud infrastructure. This article explores ENIs in depth, covering their key features, use cases, and best practices for implementation.

What is an Elastic Network Interface (ENI)?

An Elastic Network Interface (ENI) is a virtual network interface that you can attach to an EC2 instance in a VPC. Think of an ENI as a virtual network card that provides connectivity between your EC2 instances and other resources within your AWS environment.

Each ENI has the following attributes:

A primary private IPv4 address
One or more secondary IPv4 addresses
One Elastic IP address per private IPv4 address
One public IPv4 address
One or more IPv6 addresses
One or more security groups
A MAC address
A source/destination check flag
A description

Primary vs. Secondary Network Interfaces

Every EC2 instance has a default primary network interface (eth0) that cannot be detached. You can create and attach additional secondary network interfaces to your instances, with limitations based on instance type.

Key Benefits of ENIs

Enhanced Network Architecture

ENIs allow you to create complex network topologies such as:

Multi-homed instances with workloads/roles on distinct subnets
Low-budget, high-availability solutions
Network and security appliance deployments

Network Traffic Management

Create management networks separate from application traffic
Use network and security appliances in your VPC
Create dual-homed instances with workloads/roles on distinct subnets

High Availability

ENIs can be detached from one instance and attached to another
IP addresses stay with the ENI during moves
Facilitates fast failover scenarios

Common Use Cases for ENIs

1. Multi-IP Applications

Applications that require multiple IP addresses can benefit from ENIs with secondary IP addresses. For example:

Web servers hosting multiple domains with separate SSL certificates
Application servers that need to communicate on multiple subnets

2. Network Security Solutions

Security appliances like firewalls and intrusion detection systems often require:

One interface for management traffic
One or more interfaces for data traffic inspection

3. Workload Isolation

Different applications on the same instance can use different network interfaces with:

Distinct security groups
Separate subnets
Individual routing policies

4. High Availability Scenarios

When implementing high availability:

Pre-configure a standby instance with ENIs ready
During failover, detach ENIs from failed instance
Attach ENIs to standby instance
IP addresses remain consistent, minimizing DNS propagation delays

Technical Specifications and Limitations

Instance Type Considerations

The number of ENIs and IP addresses you can attach varies by instance type:

Smaller instances (t2.micro): 2-3 ENIs, 2-4 IPs per interface
Larger instances (c5.24xlarge): 15+ ENIs, 50+ IPs per interface

Performance Considerations

ENIs have bandwidth limits based on the instance type
Traffic between ENIs on the same instance stays on the host (no physical network transfer)
Enhanced Networking instances provide higher performance for network-intensive workloads

Best Practices for ENI Management

1. Security Group Configuration

Assign different security groups to different ENIs based on their function
Keep management interfaces in restricted security groups
Apply least privilege principles to each interface

2. IP Address Management

Plan your IP addressing scheme carefully
Consider using secondary IP addresses rather than multiple ENIs when possible
Use DHCP option sets to configure DNS settings

3. Monitoring and Maintenance

Tag ENIs appropriately for better resource management
Monitor network traffic per interface using CloudWatch
Regularly review security groups and network ACLs

4. Automation

Use AWS CLI or SDKs to automate ENI attachment/detachment
Implement auto-recovery scripts for failover scenarios
Consider integration with AWS Lambda for event-driven network changes

Enhanced Networking Options: ENA vs EFA vs ENA with EFA

AWS offers several networking technologies to improve performance beyond standard ENI capabilities:

Elastic Network Adapter (ENA)

ENA is AWS's primary enhanced networking technology that provides:

Higher bandwidth (up to 100 Gbps for supported instance types)
Higher packet per second (PPS) performance
Consistently lower inter-instance latencies
Lower CPU utilization for networking tasks

Most modern EC2 instance types support ENA by default. ENA uses single root I/O virtualization (SR-IOV) to provide high-performance networking capabilities, significantly improving performance compared to traditional virtualized network interfaces.

Key benefits:

Up to 100 Gbps of network bandwidth
Lower latency and jitter
Higher packets per second (PPS)
Hardware-based offloading for network functions
Automatic configuration on supported AMIs Suitable for:
General network-intensive applications
Applications requiring consistent network performance
Workloads with high throughput requirements

Elastic Fabric Adapter (EFA)

EFA is a network interface for EC2 instances designed specifically for high-performance computing (HPC) and machine learning applications that require lower latency and higher throughput than what's possible with traditional TCP transport.

Key features:

OS-bypass capability allows applications to communicate directly with the network interface
Custom-built reliable transport protocol that bypasses the operating system kernel
Support for industry-standard libfabric API
Compatible with existing Message Passing Interface (MPI) applications Suitable for:
High Performance Computing (HPC) applications
Machine Learning distributed training
Applications using MPI (Message Passing Interface)
Computational fluid dynamics, weather modeling, and similar workloads
Tightly coupled workloads requiring low-latency node-to-node communication

ENA with EFA

Some EC2 instances support both ENA and EFA simultaneously, offering the best of both worlds:

ENA provides high-bandwidth TCP/IP performance for general network traffic
EFA provides ultra-low latency OS-bypass capabilities for specialized HPC workloads Benefits of combined usage:
Maintain compatibility with standard networking applications via ENA
Utilize EFA for specific MPI or HPC workloads requiring the lowest possible latency
No need to choose between networking technologies – use both as needed Configuration considerations:
EFA requires specific security group configurations to allow all traffic between instances in the security group
EFA-enabled ENIs require specific placement in the correct subnets for cluster communication
Applications must be built with EFA-aware libraries to leverage OS-bypass capabilities

Practical Implementation Examples

Example 1: Basic Multi-Interface Configuration

# Create a new ENI in a specific subnet
aws ec2 create-network-interface \
    --subnet-id subnet-abcd1234 \
    --description "Secondary ENI" \
    --groups sg-abcd1234 \
    --private-ip-address 10.0.1.100

# Attach the ENI to an instance
aws ec2 attach-network-interface \
    --network-interface-id eni-abcd1234 \
    --instance-id i-1234567890abcdef0 \
    --device-index 1

Example 2: High Availability Setup

In a high availability scenario, you might prepare standby instances with scripts that:

Detect primary instance failure
Detach ENIs from failed instance
Attach ENIs to standby instance
Update route tables or DNS records if necessary

Potential Challenges and Solutions

Challenge 1: IP Address Exhaustion

Solution: Use secondary IP addresses on existing ENIs rather than creating new ENIs when possible.

Challenge 2: Route Table Management

Solution: Create scripts or use AWS Lambda to update route tables when ENIs are moved between instances.

Challenge 3: DNS Propagation Delays

Solution: Use Elastic IPs with ENIs and implement application-level health checks.

Conclusion

Elastic Network Interfaces provide powerful networking capabilities for EC2 instances, enabling complex network architectures, enhanced security configurations, and high availability solutions. By understanding ENI capabilities and following best practices, you can design robust and flexible cloud infrastructure that meets your organization's specific networking requirements.

Whether you're implementing multi-tier applications, security appliances, or high availability solutions, ENIs offer the flexibility and control needed to optimize your AWS network infrastructure.

AWS EC2 Instance Types

Himanshu Singh Tomar — Sat, 03 May 2025 06:46:50 +0000

Amazon EC2 provides a wide selection of instance types optimized to fit different use cases. Each instance type offers varying combinations of CPU, memory, storage, and networking capacity, giving you the flexibility to choose the appropriate mix of resources for your applications.

1. General Purpose Instances

Description: Balanced compute, memory, and networking resources.

Instance Families:

T Series (T2, T3, T3a, T4g): Burstable performance for low to moderate CPU usage.
M Series (M4, M5, M5a, M5n, M5zn, M6g, M6i, M6a, M6in, M7g, M7i, M7a, M7i-flex, M8g): Balanced resources for a broad range of workloads.

Use Cases:

Web and application servers
Development and test environments
Microservices
Small and medium databases

2. Compute Optimized Instances

Description: Ideal for compute-bound applications that benefit from high-performance processors.

Instance Families:

C Series (C4, C5, C5a, C5n, C6g, C6i, C6a, C6in, C7g, C7i): High-performance processors with a high ratio of compute to memory.

Use Cases:

High-performance web servers
Scientific modeling and batch processing
Machine learning inference
Dedicated gaming servers
Media transcoding

3. Memory Optimized Instances

Description: Designed to deliver fast performance for workloads that process large data sets in memory.

Instance Families:

R Series (R4, R5, R5a, R5n, R6g, R6i, R6a, R6in, R7g, R7i): High memory-to-CPU ratio.
X Series (X1, X1e, X2gd, X2idn, X2iedn): High memory instances for in-memory databases and real-time big data analytics.
Z Series (z1d): High compute capacity and high memory footprint.

Use Cases:

High-performance databases
In-memory caches (e.g., Redis, Memcached)
Real-time big data analytics
SAP HANA

4. Storage Optimized Instances

Description: Designed for workloads requiring high, sequential read and write access to large data sets on local storage.

Instance Families:

I Series (I3, I3en, I4i): High IOPS storage optimized for low latency.
D Series (D2, D3, D3en): Dense HDD storage for data warehousing.
H Series (H1): High disk throughput for big data workloads.

Use Cases:

NoSQL databases (e.g., Cassandra, MongoDB)
Data warehousing
Distributed file systems
Hadoop distributed computing([Medium][1], [Amazon Web Services, Inc.][2])

5. Accelerated Computing Instances

Description: Utilize hardware accelerators for functions like floating-point number calculations, graphics processing, or data pattern matching.

Instance Families:

P Series (P2, P3, P4, P4d): GPU instances for machine learning and high-performance computing.
Inf Series (Inf1): High-performance ML inference.
Trn Series (Trn1): Train ML models with high throughput.
F Series (F1): Field programmable gate arrays (FPGAs) for custom hardware acceleration.
G Series (G3, G4, G5): Graphics-intensive applications.

Use Cases:

Machine learning training and inference
High-performance computing
Video transcoding
Real-time graphics rendering([handbook.vantage.sh][3])

6. High Performance Computing (HPC) Instances

Description: Purpose-built to offer the best price performance for running high-performance computing workloads at scale on AWS.

Instance Families:

HPC Series (Hpc6id, Hpc6a): Optimized for tightly coupled, compute-intensive applications.

Use Cases:

Computational fluid dynamics
Finite element analysis
Seismic processing
Structural simulation

Instance Features

Key Features Across Instance Types:

Processor Options: Intel Xeon, AMD EPYC, AWS Graviton processors.
Networking: Enhanced Networking with up to 200 Gbps of network bandwidth.
Storage: EBS-optimized instances with high throughput.
Security: Support for always-on memory encryption using Intel Total Memory Encryption (TME).
Elastic Fabric Adapter (EFA): Support for EFA on select instances for low-latency, high-bandwidth networking.

Choosing the Right Instance Type

When selecting an EC2 instance type, consider the following factors:

Workload Requirements: Determine if your application is compute, memory, storage, or network intensive.
Performance Needs: Assess the required CPU, memory, storage, and networking performance.
Cost Optimization: Balance performance needs with budget constraints.
Scalability: Ensure the instance type supports your scalability requirements.([handbook.vantage.sh][4])

EC2 Pricing and Cost Optimization

Understanding EC2 pricing models is crucial for cost-effective cloud usage.

Pricing Models:

On-Demand: Pay for compute capacity by the hour or second with no long-term commitments.
Reserved Instances: Commit to a one- or three-year term for significant discounts.
Savings Plans: Flexible pricing model offering up to 72% savings over On-Demand pricing.
Spot Instances: Bid on spare AWS EC2 computing capacity for up to 90% off the On-Demand price.([Amazon Web Services, Inc.][2], [Amnic][5], [Medium][1])

Cost Optimization Strategies:

Rightsizing: Regularly analyze and adjust instance types to match workload requirements.
Auto Scaling: Automatically adjust the number of instances to match demand.
Monitor Usage: Use AWS Cost Explorer and other tools to monitor and analyze usage patterns.([handbook.vantage.sh][6], [Amnic][5])

EC2 Instance Pricing Comparison Tool

For detailed pricing information and comparisons across all EC2 instance types and regions, refer to instances.vantage.sh. This tool provides:

Comprehensive pricing details for On-Demand, Reserved, and Spot instances.
Filtering options by region, instance type, and pricing model.
Comparison features to evaluate different instance types side by side.
Export capabilities for customized reports.([Medium][1], [docs.vantage.sh][7])

Utilizing this tool can aid in making informed decisions to optimize both performance and cost.

For more detailed information and the latest updates on EC2 instance types, refer to the official AWS documentation: Amazon EC2 Instance Types

🚀 Deploying Sonatype Nexus on AWS EC2 using Terraform

Himanshu Singh Tomar — Sun, 13 Apr 2025 16:53:57 +0000

This guide will walk you through the steps to deploy a Nexus Repository Manager on an AWS EC2 instance using a Terraform script.

📁 Prerequisites

Make sure you have the following installed:

Terraform
AWS CLI
An AWS account with credentials configured (via aws configure)
A valid SSH key pair created in your AWS account (needed to access EC2)

📄 Step-by-Step Instructions

1. 🔑 Update Your Key Pair Name

In the aws_instance block, replace:

key_name = "your-ssh-key"

with the actual name of your AWS EC2 key pair.

2. 📦 Save the Terraform Code

Save the entire provided Terraform code into a file named main.tf in a directory of your choice.

3. 📂 Initialize Terraform

Open a terminal, navigate to the directory containing [main.tf](https://github.com/Himanshusinghtomar/Sontype-Nexus/blob/main/sontype-nexus-aws-setup.tf), and run:

terraform init

4. ✅ Validate the Configuration

Make sure everything is correct:

terraform validate

5. 🔍 Preview the Deployment

Check what Terraform is going to create:

terraform plan

6. 🚀 Apply the Terraform Plan

Create the resources:

terraform apply

Type yes when prompted to proceed.

7. 🌐 Access Nexus

Once the infrastructure is deployed, Terraform will output the public IP of the EC2 instance:

nexus_public_ip = <YOUR_PUBLIC_IP>

You can then open your browser and access Nexus:

http://<YOUR_PUBLIC_IP>:8081

The default admin password will be available in the instance at:

sudo cat /opt/sonatype-work/nexus3/admin.password

🧹 Optional: Destroy the Infrastructure

To delete the resources when you're done:

terraform destroy

Happy DevOpsing! 🎉

Setting Up Nexus Repository on AWS EC2 with Terraform and Publishing a Custom Gradle Plugin

Himanshu Singh Tomar — Sun, 13 Apr 2025 16:42:30 +0000

1. Introduction to Sonatype Nexus

What is Sonatype Nexus?

Sonatype Nexus is a powerful, open-source repository manager that allows organizations to store and manage software artifacts. It supports both internal and external repositories for various package formats such as Maven, npm, NuGet, Docker, and more. Nexus helps in managing and distributing binary artifacts, ensuring efficient version control and secure access to packages within an organization.

Why Use Nexus?

Nexus Repository provides several benefits:

Centralized Artifact Management: Nexus stores artifacts like libraries, dependencies, and Docker images, making them easy to share and reuse across different projects.
Secure Artifact Distribution: It allows for secure access to artifacts through permissions and policies, preventing unauthorized access and ensuring the integrity of software artifacts.
Supports Multiple Formats: Nexus supports different repository formats such as Maven, npm, Docker, etc., making it flexible and adaptable for various development environments.
Integration with Build Systems: Nexus can be integrated into CI/CD pipelines for automated artifact management and deployment.

2. Project Overview

In this project, we automated the installation of Sonatype Nexus on an AWS EC2 instance using Terraform and demonstrated the publishing and usage of a custom Gradle plugin through Nexus.

The project is divided into three major parts:

Deploy Nexus via Terraform
Create and Publish a Custom Gradle Plugin to Nexus
Use the Published Plugin in a Spring Boot Backend Project

3. Deploying Nexus Using Terraform

We created a Terraform configuration to:

Launch an EC2 instance
Install Java and Nexus via a shell script
Set up Nexus as a system service
Open port 8081 to access Nexus UI

Key Terraform Files:

`main.tf`

provider "aws" {
  region = "us-east-1"  # Adjust region if necessary
}

resource "aws_instance" "nexus" {
  ami           = "ami-0c55b159cbfafe1f0"  # Amazon Linux 2 AMI (adjust for your region)
  instance_type = "t3.medium"  # Adjust instance type as per your requirements
  key_name      = "your-ssh-key"  # Replace with your SSH key name

  # Security Group to allow access to port 8081 (Nexus)
  security_group = aws_security_group.nexus_sg.name

  # Instance metadata and user data to run the Nexus installation script
  user_data = <<-EOF
              #!/bin/bash
              set -e
              # Update system and install Java
              sudo apt update && sudo apt upgrade -y
              sudo apt install openjdk-8-jdk -y

              # Create nexus user
              sudo adduser --disabled-password --gecos "" nexus
              sudo usermod -aG sudo nexus

              # Download and install Nexus
              cd /opt
              sudo wget https://download.sonatype.com/nexus/3/nexus-3.70.4-02-java8-unix.tar.gz
              sudo tar -xvzf nexus-3.70.4-02-java8-unix.tar.gz
              sudo mv nexus-3.70.4-02 nexus
              sudo chown -R nexus:nexus /opt/nexus

              # Configure Nexus to run as nexus user
              echo 'run_as_user="nexus"' | sudo tee /opt/nexus/bin/nexus.rc

              # Create systemd service for Nexus
              cat <<EOF2 | sudo tee /etc/systemd/system/nexus.service
              [Unit]
              Description=Nexus Repository Manager
              After=network.target

              [Service]
              Type=forking
              LimitNOFILE=65536
              ExecStart=/opt/nexus/bin/nexus start
              ExecStop=/opt/nexus/bin/nexus stop
              User=nexus
              Restart=on-abort

              [Install]
              WantedBy=multi-user.target
              EOF2

              # Reload systemd and enable Nexus service
              sudo systemctl daemon-reexec
              sudo systemctl daemon-reload
              sudo systemctl enable nexus
              sudo systemctl start nexus

              # Print default admin password and Nexus URL
              echo -e "\n✅ Nexus is installed and running on port 8081."
              sudo cat /opt/sonatype-work/nexus3/admin.password
              echo -e "\n💡 Access Nexus at: http://$(curl -s http://169.254.169.254/latest/meta-data/public-ipv4):8081"
              EOF

  # Tags for the instance
  tags = {
    Name = "Nexus Server"
  }
}

# Security group to allow HTTP and HTTPS access
resource "aws_security_group" "nexus_sg" {
  name        = "nexus_sg"
  description = "Allow HTTP, HTTPS, and SSH access"

  ingress {
    from_port   = 8081
    to_port     = 8081
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

output "nexus_public_ip" {
  value = aws_instance.nexus.public_ip
  description = "The public IP address of the Nexus server"
}

Nexus Status

4. Creating a Custom Gradle Plugin

We created a Gradle plugin project to define reusable logic. Here’s how:

`build.gradle`

plugins {
    id 'java-gradle-plugin'
    id 'maven-publish'
}

group = 'com.dependencie'
version = '1.0.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    implementation gradleApi()
    implementation localGroovy()
}

gradlePlugin {
    plugins {
        backendPublisher {
            id = 'com.dependencie.nexusplugin'
            implementationClass = 'com.dependencie.nexusplugin.BackendPublisherPlugin'
        }
    }
}

publishing {
    repositories {
        maven {
            name = "nexusSnapshots"
            url = uri("http://<your-ec2-ip>:8081/repository/maven-snapshots/")
            allowInsecureProtocol = true
            credentials {
                username = "admin"
                password = "12345"
            }
        }
    }
}

Plugin Implementation (`BackendPublisherPlugin.java`)

package com.dependencie.nexusplugin;

import org.gradle.api.Plugin;
import org.gradle.api.Project;


public class BackendPublisherPlugin implements Plugin<Project> {

    @Override
    public void apply(Project project) {
        project.getPluginManager().apply("java");
        project.getPluginManager().apply("org.springframework.boot");
        project.getPluginManager().apply("io.spring.dependency-management");

        project.setGroup("com.example");
        project.setVersion("0.0.1-SNAPSHOT");

        project.getExtensions().getExtraProperties().set("springBootVersion", "3.4.4");

        project.getRepositories().mavenCentral();

        project.getDependencies().add("implementation", "org.springframework.boot:spring-boot-starter-data-jpa");
        project.getDependencies().add("implementation", "org.springframework.boot:spring-boot-starter-web");
        project.getDependencies().add("implementation", "org.springframework.boot");
        project.getDependencies().add("compileOnly", "org.projectlombok:lombok");
        project.getDependencies().add("runtimeOnly", "com.h2database:h2");
        project.getDependencies().add("annotationProcessor", "org.projectlombok:lombok");
        project.getDependencies().add("testImplementation", "org.springframework.boot:spring-boot-starter-test");
        project.getDependencies().add("testRuntimeOnly", "org.junit.platform:junit-platform-launcher");
    }
}

Publishing the Plugin

Run this in the plugin project root:

./gradlew publish

The plugin will be published to your Nexus snapshot repository.

5. Using the Custom Plugin in a Backend Project

Once published, we integrated the custom plugin into a Spring Boot project.

Backend Project Structure

settings.gradle

pluginManagement {
    repositories {
        maven {
            url = uri("http://<your-ec2-ip>:8081/repository/maven-snapshots/")
            allowInsecureProtocol = true
            credentials {
                username = "admin"
                password = "12345"
            }
        }
        gradlePluginPortal()
        mavenCentral()
    }
}
rootProject.name = 'employee-management'

build.gradle

plugins {
    id 'com.dependencie.nexusplugin' version '1.0.0-SNAPSHOT'
    id 'java'
    id 'org.springframework.boot' version '3.4.4'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

repositories {
    mavenCentral()
    maven {
        url = uri("http://<your-ec2-ip>:8081/repository/maven-snapshots/")
        allowInsecureProtocol = true
        credentials {
            username = "admin"
            password = "12345"
        }
    }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    compileOnly 'org.projectlombok:lombok'
    annotationProcessor 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

tasks.named('test') {
    useJUnitPlatform()
}

Verify Plugin Integration

Run:

./gradlew helloPlugin

Output:

✅ Custom Nexus Plugin Applied Successfully!

6. Conclusion

In this end-to-end setup, we:

Deployed Sonatype Nexus on AWS EC2 using Terraform
Created and published a custom Gradle plugin to Nexus
Integrated that plugin into a Spring Boot backend project

This setup can be expanded further to publish internal libraries, enforce quality gates, or share reusable Gradle logic across teams.

Building a Chat Application with Ollama's DeepSeek Model

Himanshu Singh Tomar — Mon, 27 Jan 2025 12:59:08 +0000

Prerequisites

Before diving in, ensure you have the following:

A macOS system (Ollama is macOS-specific).
Homebrew installed for package management.
Basic familiarity with Angular or JavaScript for frontend development.
You can download Ollama for all operating systems from https://ollama.com/download.

Step 1: Installing Ollama

Install Ollama using Homebrew by running the following command:

brew install ollama

Once installed, start the Ollama service:

ollama serve

This launches the Ollama server locally, typically accessible at http://localhost:11434.

Step 2: Installing the Model

To use the DeepSeek model, you first need to pull it into your local setup. Run the command:

ollama pull deepseek-r1:8b

This will download the model locally so it’s ready for use. If performance is a concern, consider pulling a smaller version of the model (e.g., deepseek-r1:3b) if available.

Step 3: Testing the Model Locally

To ensure everything is working, test the model by initiating a chat session:

ollama chat deepseek-r1:8b

Type your prompts and see the responses in your terminal. Exit the session when you’re ready to move forward.

Step 4: Interacting with the Model via API

Ollama provides an API endpoint that allows programmatic interaction with installed models. Here’s how you can do it in Angular.

Setting Up Angular Project

Install Angular CLI (if not already installed):

   npm install -g @angular/cli

Create a new Angular project:

   ng new chat-app

Add HttpClientModule: Update your AppModule to include HttpClientModule:

   import { HttpClientModule } from '@angular/common/http';

   @NgModule({
     declarations: [AppComponent],
     imports: [BrowserModule, HttpClientModule],
     providers: [],
     bootstrap: [AppComponent],
   })
   export class AppModule {}

Angular Service for Chat

Create a service to handle API communication:

import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class ChatService {
  url = 'http://localhost:11434/api/chat';

  constructor(private http: HttpClient) {}

  getChat(chatInput: string) {
    const payload = {
      model: 'deepseek-r1:8b',
      messages: [
        { role: 'user', content: chatInput },
      ],
      stream: false,
    };

    return this.http.post(this.url, payload);
  }
}

Angular Component for Chat

Use the service in a component to interact with the API:

import { Component } from '@angular/core';
import { ChatService } from './chat.service';

@Component({
  selector: 'app-root',
  template: `
    <div>
      <input [(ngModel)]="chatInput" placeholder="Type your message" />
      <button (click)="sendMessage()">Send</button>
    </div>
    <div *ngIf="chatResponse">
      <p>{{ chatResponse }}</p>
    </div>
  `,
})
export class AppComponent {
  chatInput = '';
  chatResponse = '';

  constructor(private chatService: ChatService) {}

  sendMessage() {
    this.chatService.getChat(this.chatInput).subscribe(
      (response: any) => {
        this.chatResponse = response.message.content; // Adjust as per API response structure
      },
      (error) => {
        console.error('Error:', error);
      }
    );
  }
}

Step 5: Optimizing Response Time

If you notice that responses take too long, here are some optimizations:

1. Use a Smaller Model

Switch to a smaller version of the model if available:

const payload = {
  model: 'deepseek-r1:3b', // Smaller model for faster responses
  messages: [
    { role: 'user', content: this.chatInput },
  ],
  stream: false,
};

2. Add a System Message

Guide the model to produce concise responses:

const payload = {
  model: 'deepseek-r1:8b',
  messages: [
    { role: 'system', content: 'Respond concisely in plain text without Markdown or unnecessary tags.' },
    { role: 'user', content: this.chatInput },
  ],
  stream: false,
};

3. Enable Streaming

Streaming allows partial responses to be sent as they’re generated:

const payload = {
  model: 'deepseek-r1:8b',
  messages: [
    { role: 'user', content: this.chatInput },
  ],
  stream: true,
};

Handle the streamed response in chunks for faster perceived responses.

4. Optimize Server Performance

Ensure the server has sufficient resources (CPU, memory, or GPU). If necessary, scale up your system resources to handle the model efficiently.

Conclusion

In this guide, we explored how to set up and use Ollama's DeepSeek model with Angular. From installation to API integration and optimization, you now have a complete roadmap for building a functional chat application. By applying these techniques, you can ensure your application is both responsive and efficient.

Feel free to experiment with system prompts and smaller models to tailor the chat experience to your needs. Happy coding!

Understanding Angular Life Cycle Hooks

Himanshu Singh Tomar — Sat, 25 Jan 2025 10:18:19 +0000

Angular is one of the most popular front-end frameworks for building dynamic web applications. A key aspect of Angular's power and flexibility lies in its component lifecycle hooks. These hooks provide developers with fine-grained control over how components and directives behave during their lifecycle. In this blog post, we will explore the most important lifecycle hooks that are commonly used in Angular applications, followed by a detailed explanation of all lifecycle hooks.

What Are Angular Life Cycle Hooks?

Lifecycle hooks are methods in a component or directive that Angular calls during specific stages of its creation, update, and destruction. By implementing these hooks, you can perform actions at crucial moments in a component's lifecycle, such as initializing data, responding to changes, or cleaning up resources.

The Most Important Angular Lifecycle Hooks

Here is a list of the most commonly used lifecycle hooks, along with their purpose and usage:

1. ngOnChanges

Purpose: Responds to changes in the input properties bound to the component.
Signature: ngOnChanges(changes: SimpleChanges): void
When Called: Before ngOnInit, whenever an input property changes.

This hook is particularly useful when a component depends on dynamically changing input values.

ngOnChanges(changes: SimpleChanges): void {
  console.log('Input property changed:', changes);
}

2. ngOnInit

Purpose: Used for component initialization, such as setting up data or making API calls.
Signature: ngOnInit(): void
When Called: Once, after the first ngOnChanges.

This is one of the most frequently used hooks in Angular.

ngOnInit(): void {
  console.log('Component initialized');
}

3. ngAfterViewInit

Purpose: Responds after Angular initializes the component's views and child views.
Signature: ngAfterViewInit(): void
When Called: Once, after the component's view is initialized.

This hook is crucial when working with DOM manipulations or third-party libraries that depend on the DOM.

ngAfterViewInit(): void {
  console.log('View initialized');
}

4. ngOnDestroy

Purpose: Performs cleanup before the component is destroyed.
Signature: ngOnDestroy(): void
When Called: Just before the component is removed from the DOM.

This hook is essential for preventing memory leaks by unsubscribing from observables or removing event listeners.

ngOnDestroy(): void {
  console.log('Component destroyed');
}

Detailed Explanation of All Angular Lifecycle Hooks

In addition to the most commonly used hooks, Angular provides several other lifecycle hooks that can be leveraged in specific scenarios:

ngDoCheck

Purpose: Detects and acts upon changes that Angular doesn't detect automatically.
Signature: ngDoCheck(): void
When Called: During every change detection cycle.

ngDoCheck(): void {
  console.log('Change detection triggered');
}

ngAfterContentInit

Purpose: Responds after Angular projects external content into the component.
Signature: ngAfterContentInit(): void
When Called: Once, after the first content projection.

ngAfterContentInit(): void {
  console.log('Content projected into the component');
}

ngAfterContentChecked

Purpose: Responds after Angular checks the projected content.
Signature: ngAfterContentChecked(): void
When Called: After every change detection cycle.

ngAfterContentChecked(): void {
  console.log('Projected content checked');
}

ngAfterViewChecked

Purpose: Responds after Angular checks the component's views and child views.
Signature: ngAfterViewChecked(): void
When Called: After every change detection cycle.

ngAfterViewChecked(): void {
  console.log('View checked');
}

Best Practices for Using Lifecycle Hooks

Focus on Common Hooks: While Angular provides many lifecycle hooks, focus on the most commonly used ones: ngOnChanges, ngOnInit, ngAfterViewInit, and ngOnDestroy.
Avoid Memory Leaks: Always clean up resources like subscriptions or event listeners in the ngOnDestroy hook.
Leverage ngOnInit: Initialize data and make API calls in ngOnInit rather than the constructor for better separation of concerns.

Conclusion

The lifecycle hooks ngOnChanges, ngOnInit, ngAfterViewInit, and ngOnDestroy are the most important and frequently used hooks in Angular development. However, understanding all lifecycle hooks such as ngDoCheck, ngAfterContentInit, ngAfterContentChecked, and ngAfterViewChecked ensures you have full control over your component's behavior. By mastering these hooks, you can deliver robust, high-quality applications with Angular.

Happy coding!

How to Work with HashMap in Java

Himanshu Singh Tomar — Fri, 24 Jan 2025 18:22:53 +0000

HashMap is a powerful data structure in Java that allows you to store and manage key-value pairs efficiently. This guide will cover the basics of working with HashMap, including commonly used methods and examples to help you understand its usage.

Introduction to HashMap

A HashMap stores data in the form of key-value pairs and provides constant-time complexity for basic operations like put, get, and remove (on average). Here's why HashMap is so useful:

Keys are unique, but values can be duplicated.
Keys and values can be of any object type.
It is part of the java.util package.
It allows null as a key or value.

Example:

import java.util.HashMap;

public class HashMapExample {
    public static void main(String[] args) {
        HashMap<Integer, String> map = new HashMap<>();

        // Adding key-value pairs
        map.put(1, "Apple");
        map.put(2, "Banana");
        map.put(3, "Cherry");

        // Accessing a value
        System.out.println(map.get(1)); // Output: Apple
    }
}

Creating a HashMap

To create a HashMap, use the following syntax:

HashMap<KeyType, ValueType> mapName = new HashMap<>();

Example:

HashMap<String, Integer> frequencyMap = new HashMap<>();

Here, the key type is String and the value type is Integer.

Commonly Used Methods

Here are the key methods of HashMap:

1. `put(K key, V value)`

Description: Adds a key-value pair to the map. If the key already exists, it updates the value.
Example:

  HashMap<Integer, String> map = new HashMap<>();
  map.put(1, "Apple");
  map.put(2, "Banana");
  map.put(1, "Cherry"); // Updates value for key 1
  System.out.println(map); // Output: {1=Cherry, 2=Banana}

2. `get(Object key)`

Description: Retrieves the value associated with the specified key. Returns null if the key is not found.
Example:

  System.out.println(map.get(1)); // Output: Cherry
  System.out.println(map.get(3)); // Output: null

3. `getOrDefault(Object key, V defaultValue)`

Description: Retrieves the value for the specified key. Returns defaultValue if the key is not found.
Example:

  System.out.println(map.getOrDefault(3, "Default")); // Output: Default

4. `containsKey(Object key)`

Description: Checks if the map contains the specified key.
Example:

  System.out.println(map.containsKey(1)); // Output: true
  System.out.println(map.containsKey(3)); // Output: false

5. `containsValue(Object value)`

Description: Checks if the map contains the specified value.
Example:

  System.out.println(map.containsValue("Cherry")); // Output: true
  System.out.println(map.containsValue("Orange")); // Output: false

6. `remove(Object key)`

Description: Removes the entry for the specified key and returns the value. Returns null if the key is not found.
Example:

  System.out.println(map.remove(1)); // Output: Cherry
  System.out.println(map); // Output: {2=Banana}

7. `putIfAbsent(K key, V value)`

Description: Adds a key-value pair only if the key is not already present in the map.
Example:

  map.putIfAbsent(3, "Orange");
  System.out.println(map); // Output: {2=Banana, 3=Orange}

8. `replace(K key, V value)`

Description: Replaces the value associated with the key, only if the key exists.
Example:

  map.replace(3, "Grapes");
  System.out.println(map); // Output: {2=Banana, 3=Grapes}

9. `keySet()`

Description: Returns a Set containing all the keys in the map.
Example:

  System.out.println(map.keySet()); // Output: [2, 3]

10. `values()`

Description: Returns a Collection of all the values in the map.
Example:

  System.out.println(map.values()); // Output: [Banana, Grapes]

11. `entrySet()`

Description: Returns a Set of all key-value pairs (Map.Entry) in the map.
Example:

  for (var entry : map.entrySet()) {
      System.out.println(entry.getKey() + " -> " + entry.getValue());
  }
  // Output:
  // 2 -> Banana
  // 3 -> Grapes

12. `compute(K key, BiFunction<? super K, ? super V, ? extends V> remappingFunction)`

Description: Updates the value for the given key using a computation function.
Example:

  map.put(1, 10);
  map.compute(1, (k, v) -> v * 2); // Doubles the value
  System.out.println(map); // Output: {1=20}

13. `merge(K key, V value, BiFunction<? super V, ? super V, ? extends V> remappingFunction)`

Description: Combines a new value with the existing value for the given key.
Example:

  map.put(1, 10);
  map.merge(1, 5, Integer::sum); // Adds the values
  System.out.println(map); // Output: {1=15}

Full Example: Word Frequency Counter

Here is a complete example that demonstrates how to use HashMap to count the frequency of words:

import java.util.HashMap;

public class WordFrequency {
    public static void main(String[] args) {
        String[] words = {"apple", "banana", "apple", "orange", "banana", "apple"};
        HashMap<String, Integer> frequencyMap = new HashMap<>();

        for (String word : words) {
            frequencyMap.put(word, frequencyMap.getOrDefault(word, 0) + 1);
        }

        System.out.println(frequencyMap); // Output: {orange=1, banana=2, apple=3}
    }
}

Conclusion

The HashMap class is a versatile and efficient way to manage key-value pairs in Java. By understanding its methods, you can solve a wide range of problems, from simple lookups to complex data manipulations. Start using HashMap in your projects to leverage its power!

Automating Google Meet Creation

Himanshu Singh Tomar — Wed, 15 Jan 2025 10:28:01 +0000

Automating Google Meet Creation with Google Calendar API and Service Account

In this blog post, we will walk through the process of automatically creating a Google Meet link by creating a Google Calendar event using the Google Calendar API. We'll use a service account to authenticate, making it possible to create events on behalf of a user in your Google Workspace domain.

Prerequisites

Before we get started, make sure you have the following:

A Google Cloud Project with the Google Calendar API enabled.
A Service Account created and its JSON key file downloaded.
Domain-Wide Delegation of Authority enabled for the Service Account.
Access to your Google Admin Console to grant the necessary permissions.
Basic knowledge of Node.js and API requests.

Steps to Create Google Meet Automatically

Step 1: Set Up Google Cloud Project

Go to the Google Cloud Console.
Create a new project or select an existing one.
Enable the Google Calendar API:
- In the sidebar, search for Calendar API and enable it for your project.
Create a Service Account:
- In the IAM & Admin section, create a new service account.
- Download the JSON key for the service account.

Step 2: Enable Domain-Wide Delegation

Go to the Google Admin Console (admin.google.com).
Navigate to Security → API Controls → Manage Domain-Wide Delegation.
Add a new Client ID for the service account:
- Find the Client ID in the Google Cloud Console under your service account.
- Add the service account’s OAuth scopes, which are required for accessing Google Calendar:
  - https://www.googleapis.com/auth/calendar
Grant the service account permission to impersonate users in your domain.

Step 3: Install Required Packages

You need a few Node.js packages to interact with the Google API and handle JWT signing:

npm install google-auth-library jsonwebtoken node-fetch

Step 4: Generate JWT Token for Authentication

Next, we’ll write a Node.js script to generate a JWT (JSON Web Token) to authenticate the service account.

const fs = require('fs');
const jwt = require('jsonwebtoken');

// Path to your service account JSON file
const SERVICE_ACCOUNT_KEY_FILE = '/path/to/your/service-account-key.json';

// Scopes required for the API
const SCOPES = ['https://www.googleapis.com/auth/calendar']; // Full calendar access
const AUDIENCE = 'https://oauth2.googleapis.com/token';

async function generateJWT() {
    try {
        // Read and parse the service account credentials
        const serviceAccount = JSON.parse(fs.readFileSync(SERVICE_ACCOUNT_KEY_FILE, 'utf8'));

        // JWT payload
        const jwtPayload = {
            iss: serviceAccount.client_email,       // Issuer: service account email
            sub: 'user@example.com',                // Subject: email of the user whose calendar to access
            aud: AUDIENCE,                          // Audience: Google token URL
            scope: SCOPES.join(' '),                // Scopes: space-separated list of scopes
            iat: Math.floor(Date.now() / 1000),     // Issued at: current time in seconds
            exp: Math.floor(Date.now() / 1000) + 3600 // Expiration: 1 hour from now
        };

        // Sign the JWT using the service account's private key
        const signedJwt = jwt.sign(jwtPayload, serviceAccount.private_key, { algorithm: 'RS256' });

        console.log('Generated JWT:', signedJwt);
    } catch (error) {
        console.error('Error generating JWT:', error);
    }
}

generateJWT();

Step 5: Exchange JWT for OAuth 2.0 Token

Now, use the JWT to obtain an OAuth 2.0 token from Google’s OAuth 2.0 token endpoint:

const fetch = require('node-fetch');

async function getAccessToken(signedJwt) {
    const response = await fetch('https://oauth2.googleapis.com/token', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
        },
        body: new URLSearchParams({
            'grant_type': 'urn:ietf:params:oauth:grant-type:jwt-bearer',
            'assertion': signedJwt
        })
    });
    const data = await response.json();
    return data.access_token;
}

Step 6: Create a Google Calendar Event with Google Meet Link

Using the access token, we can now create a Google Calendar event with a Google Meet link.

async function createCalendarEvent(accessToken) {
    const eventData = {
        summary: "Meeting with Rajeen Test",
        description: "Discuss project updates",
        start: {
            dateTime: "2025-01-16T10:00:00+05:30", // Start time in IST
            timeZone: "Asia/Kolkata"               // Explicitly specify IST time zone
        },
        end: {
            dateTime: "2025-01-16T12:00:00+05:30", // End time in IST
            timeZone: "Asia/Kolkata"               // Explicitly specify IST time zone
        },
        attendees: [
            { email: "attendees1@gmail.com" },
            { email: "attendees2@pieworks.in" }
        ],
        conferenceDataVersion: 1, // Add this to enable Meet links
        conferenceData: {
            createRequest: {
                conferenceSolutionKey: { type: "hangoutsMeet" },
                requestId: "unique-request-id"
            }
        }
    };


    const response = await fetch('https://www.googleapis.com/calendar/v3/calendars/primary/events?conferenceDataVersion=1&sendUpdates=all', {
        //&sendUpdates=all (this is to send maill notification)
        method: 'POST',
        headers: {
            'Authorization': `Bearer ${accessToken}`,
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(eventData)
    });

    const responseBody = await response.json();

    if (!response.ok) {
        console.error('Error creating event:', responseBody);
        throw new Error('Failed to create calendar event');
    }

    console.log('Event created successfully:', responseBody);
    console.log('Meet Link:', responseBody.hangoutLink); // Print the Google Meet link
}

Step 7: Run the Full Process

Combine all the parts and run the script to create the Google Meet event automatically.

(async () => {
    const signedJwt = await generateJWT();
    const accessToken = await getAccessToken(signedJwt);
    await createEvent(accessToken);
})();

Conclusion

With the above steps, you can create Google Calendar events with Google Meet links automatically, using a service account and Domain-Wide Delegation of Authority. This method is perfect for automating meetings in a Google Workspace domain.

By enabling Domain-Wide Delegation and configuring the service account to impersonate users, you can access and manage Google Calendar events programmatically, which is extremely useful for enterprise environments.

Happy coding! ✨