Forem: Mridu Dixit

Stop Calling Functions in Angular Templates — It’s Slower Than You Think

Mridu Dixit — Wed, 01 Apr 2026 14:25:42 +0000

Calling functions in Angular templates looks clean:

<p>{{ getFullName() }}</p>

But this pattern has a hidden cost.

It’s not about correctness — it’s about how often Angular executes that function.

⚙️ What’s Really Happening

Angular does not cache template function calls.

Every change detection cycle re-evaluates:

{{ getFullName() }}

Even if:

the data hasn’t changed
the result is identical
nothing visible updates

The function still runs.

🚨 Why This Becomes a Problem

Change Detection Runs More Than You Think

Triggered by:

user interactions
async events
signals updating
parent component changes

Each trigger = function execution again.

It Explodes Inside Lists

<li *ngFor="let user of users">
  {{ getFullName(user) }}
</li>

100 items = 100 executions
Per cycle.

Now add:

filtering
formatting
derived calculations

That’s where performance quietly degrades.

Cost Is Invisible Until It’s Not

The real issue isn’t small functions — it’s what they turn into over time.

Today:

return user.name;

Tomorrow:

formatting
conditionals
nested logic

Same template. Very different cost.

❌ The Problem Pattern

getFullName(user: User) {
  return `${user.firstName} ${user.lastName}`;
}

<p>{{ getFullName(user) }}</p>

Looks harmless. Scales poorly.

✅ Better Patterns

Precompute Values

user = {
  ...rawUser,
  fullName: `${rawUser.firstName} ${rawUser.lastName}`
};

<p>{{ user.fullName }}</p>

Simple. Predictable. Fast.

Use Signals (computed)

fullName = computed(() =>
  `${this.user().firstName} ${this.user().lastName}`
);

<p>{{ fullName() }}</p>

Recomputes only when dependencies change.

Use Pure Pipes

<p>{{ user | fullName }}</p>

Pure pipes are memoized by Angular — they don’t recompute unnecessarily.

🧠 When Is It Actually Okay?

Template function calls are acceptable if:

the logic is trivial
not inside loops
not called frequently

But in most real apps:

Template functions are a scaling risk, not an immediate bug.

⚡ Rule of Thumb

If it’s inside a template:

assume it runs many times
keep it cheap or precomputed

🔥 Final Thought

Angular performance isn’t about micro-optimizations.

It’s about predictability.

Templates should describe UI —
not execute logic repeatedly.

What feels clean now can become your slowest path later.

You Don’t Need NgRx Anymore — Or Do You?

Mridu Dixit — Tue, 17 Mar 2026 18:12:53 +0000

For years, NgRx was the go-to solution for state management in Angular.

Actions.
Reducers.
Effects.
Selectors.

It brought structure, predictability, and scalability.

But Angular has changed.

With Signals, simpler services, and better reactivity, many developers are asking:

Do we still need NgRx?

The answer isn’t a simple yes or no.

🚀 Why NgRx Was So Popular

NgRx solved real problems:

Centralized state
Predictable data flow
Debugging with DevTools
Great for large, complex apps

For enterprise-scale applications, this structure was a lifesaver.

⚡ What Changed in Angular

Modern Angular introduced:

Signals (signal, computed, effect)
Better component-level state
Cleaner reactivity without heavy RxJS

Example without NgRx:

@Injectable()
export class UserStore {
  private users = signal<User[]>([]);

  activeUsers = computed(() =>
    this.users().filter(u => u.active)
  );

  setUsers(data: User[]) {
    this.users.set(data);
  }
}

No reducers.
No actions.
No boilerplate.

Just state + logic.

🤔 So… Do You Still Need NgRx?

❌ You Probably DON’T Need NgRx If:

Your app is small to medium
State is mostly local or feature-based
You don’t need time-travel debugging
You prefer simpler, faster development

Signals + services are often enough.

✅ You STILL Need NgRx If:

You have a large enterprise app
Multiple teams work on the same codebase
State is deeply shared and complex
You need strict patterns and tooling
Debugging state transitions is critical

NgRx shines in complex systems, not simple apps.

⚠️ T*he Real Problem: Over-Engineering*

Many apps adopted NgRx too early.

Result:

Too much boilerplate
Slower development
Harder onboarding

Using NgRx for simple state is like:

using a microservices architecture for a to-do app

🔥 Signals vs NgRx — The Real Difference

Signals NgRx
Simple Structured
Minimal boilerplate Heavy boilerplate
Great for local state Great for global state
Easy to learn Steeper learning curve

This is not a replacement — it’s a tradeoff.

🧠 The Better Approach

You don’t have to choose one.

Use:

Signals for local/component state
NgRx for global, complex workflows This hybrid approach works best in real apps.

⚡ A Practical Rule

👉 Start with Signals
👉 Add NgRx only when complexity demands it

Not the other way around.

🔚 Final Thought

NgRx is not outdated.

But it’s no longer the default.

Angular has evolved — and so should your approach to state management.

The real skill isn’t choosing a tool.

It’s knowing when you actually need it.

Signals Made Angular Faster — But Also Easier to Misuse

Mridu Dixit — Wed, 18 Feb 2026 16:06:39 +0000

Angular Signals changed everything.

No more heavy RxJS for simple state.
No more manual subscriptions everywhere.
Finer-grained reactivity.
Better performance.

But here’s the uncomfortable truth:

Signals made Angular faster — and also much easier to misuse.

Let’s talk about where developers are getting it wrong.

🚀 Why Signals Are Powerful

Signals give Angular:

Fine-grained reactivity
Automatic dependency tracking
Cleaner state management
Better compatibility with zoneless apps

Example:

count = signal(0);

increment() {
  this.count.update(v => v + 1);
}

Template:

<p>{{ count() }}</p>

Simple. Reactive. Fast.

But speed + simplicity can create new problems.

❌ Misuse #1: Calling Signals Excessively in Templates

Bad pattern:

<p>{{ expensiveComputed() }}</p>
<p>{{ expensiveComputed() }}</p>
<p>{{ expensiveComputed() }}</p>

Each call re-evaluates dependencies.

If your computed logic is heavy, you just created hidden performance cost.

✔ Fix:
Store in a local template variable or simplify computed logic.

❌ Misuse #2: Overusing computed() for Heavy Logic

Bad pattern:

filteredUsers = computed(() => {
  return this.users()
    .filter(u => u.active)
    .sort(...)
    .map(...);
});

If users() changes often, this recalculates fully.

Signals are reactive — not magical.

✔ Fix:

Break computations
Normalize state
Avoid expensive transformations inside computed

❌ Misuse #3: Using Effects Like Subscriptions

Developers are replacing RxJS subscriptions with effects everywhere.

Bad pattern:

effect(() => {
  console.log(this.user());
});

Effects should be rare and intentional.

Too many effects:

cause cascading updates
create debugging nightmares
feel like hidden side-effects

✔ Rule:
Use computed() for derivation.
Use effect() only for external side effects.

❌ Misuse #4: Treating Signals Like Global State

Putting everything in a service:

user = signal(null);
cart = signal([]);
theme = signal('light');

Now your app becomes tightly coupled and hard to test.

Signals are reactive primitives — not architecture.

❌ Misuse #5: Mixing Signals and RxJS Without Boundaries

Many apps now look like this:

signals
observables
subjects
effects
async pipe

All together.

That’s not progress.
That’s confusion.

✔ Decide:

UI state → signals
Streams & async flows → RxJS
Keep boundaries clear

🧠 The Real Shift Signals Introduced

Signals changed Angular’s mental model:

From:

"Change detection runs everywhere"

To:

"Reactivity happens where dependencies exist"

But this requires discipline.

Signals reward:

clean state modeling
small derivations
clear boundaries

They punish:

heavy computations
hidden effects
sloppy architecture

⚡ Are Signals Worth It?

Absolutely.

They:

reduce unnecessary checks
improve performance clarity
simplify component state
work beautifully with zoneless Angular

But performance doesn’t come from using signals.

It comes from using them correctly.

🔥 Final Thought

Signals didn’t just make Angular faster.

They made Angular more powerful.

And with more power comes the ability to:

write elegant code
or create subtle performance bugs

The choice is yours.

Why Your App Is Secure… Until the First API Call

Mridu Dixit — Thu, 12 Feb 2026 14:54:27 +0000

Your app looks secure.

And yet — the moment the first API call is made, most apps quietly fall apart.

This isn’t a theory problem.
It’s one of the most common security failures in modern web apps.

Let’s talk about why.

The Illusion of Security in Frontend Apps

Most apps rely heavily on:

route guards
UI-based permissions
role-based rendering
client-side checks

Example:

if (user.role === 'admin') {
  showAdminPanel();
}

This looks secure, but it’s only cosmetic.

Anyone can:

open DevTools
intercept requests
call your API directly

The UI is not your security boundary.

The First API Call Is the Real Test

Here’s where things break.

POST /api/delete-user
Authorization: Bearer <token>

Questions most apps don’t answer properly:

Who is allowed to call this?
What role is required?
Does this user own the resource?
Is this request replayable?

If the backend trusts the frontend — you already lost.

Myth: “We Use JWT, So We’re Secure”

JWTs only prove:

Someone logged in.

They do not prove:

permission
ownership
intent

Bad pattern ❌:

const userId = req.body.userId;
deleteUser(userId);

Correct pattern ✅:

const userId = req.auth.userId;
deleteUser(userId);

The server must derive identity, not accept it.

Myth: “Routes Are Protected”

Protecting pages ≠ protecting APIs.

Anyone can call:

curl https://api.yourapp.com/delete-user

Even if the page is hidden.

APIs must protect themselves. Always.

Common First-API-Call Security Mistakes

❌ Trusting client-sent IDs

{ "userId": "123" }

❌ Role checks only in frontend

if (isAdmin) { ... }

❌ No ownership validation

deletePost(postId);

❌ Assuming “internal API” means safe

What Real API Security Looks Like

Every API call should answer three questions:

1️⃣ Who is calling?

Validate token
Extract identity on server

2️⃣ Are they allowed?

Role-based checks
Permission-based checks

3️⃣ Do they own the resource?

User ↔ data relationship
Tenant isolation

If any answer is missing — it’s a vulnerability.

Frontend’s Real Responsibility
Frontend security is about:

preventing accidental misuse
improving UX
reducing obvious errors

It is not about enforcing trust.

The backend must assume:

Every request is hostile until proven otherwise.

Why This Keeps Happening

Because modern stacks make it easy to:

build fast
ship auth quickly
hide complexity

But security doesn’t come from tools.
It comes from boundaries.

Final Takeaway

If your security model breaks when someone skips the UI —
your app was never secure.

The first API call is where:

trust should end
validation should begin
real security lives

Using Prisma with Next.js and Supabase — What Actually Works (and What Doesn’t)

Mridu Dixit — Fri, 30 Jan 2026 13:20:23 +0000

Next.js, Supabase, and Prisma are often mentioned together — but the integration isn’t always obvious.

Should you use Supabase as a database, as auth only, or both?
Where does Prisma fit when Supabase already exposes Postgres?

Let’s clear the confusion and look at real-world usage patterns.

The Real Roles (Clear This First)

🔹 Supabase

Managed PostgreSQL
Authentication (JWT-based)
Realtime, Storage, Edge Functions
Auto-generated REST & GraphQL APIs

🔹 Prisma

Type-safe ORM
Schema-driven data modeling
Migrations
Excellent DX for complex queries

🔹 Next.js

App Router / Server Actions
API routes
SSR / SSG / ISR
Backend + frontend in one app

👉 Supabase ≠ Prisma replacement
👉 Prisma ≠ Auth provider

They solve different problems.

Most Common (and Best) Architecture

✅ Supabase for:

PostgreSQL hosting
Authentication
Row Level Security (RLS)
Storage

✅ Prisma for:

Database access
Complex queries
Business logic
Type safety

✅ Next.js for:

UI
Server Actions
API orchestration
This combo gives you control + safety + speed.

How Prisma Connects to Supabase

Supabase is just Postgres under the hood.

You connect Prisma using the direct database URL:

DATABASE_URL="postgresql://user:password@db.supabase.co:5432/postgres"

Then define your Prisma schema normally:

model User {
  id        String   @id @default(uuid())
  email     String   @unique
  createdAt DateTime @default(now())
}

Run:

npx prisma migrate dev

Prisma migrations work perfectly with Supabase.

Auth: Supabase Auth + Prisma (Important Pattern)

Supabase Auth users live in:

auth.users

Best practice:

Do not manage auth users with Prisma
Reference auth.users.id in your tables

Example:

model Profile {
  id     String @id
  userId String @unique
  name   String
}

Then sync on signup using:

Supabase Edge Functions
Next.js Server Actions
Webhooks

Row Level Security (RLS) vs Prisma — The Tradeoff

⚠️ Important Truth

Prisma bypasses Supabase RLS when using the service role or DB URL.

That means:

RLS does not protect Prisma queries
You must enforce authorization in your backend

Best Practice:

Use Prisma only in server-side code
Validate user identity from Supabase JWT
Apply access rules in Prisma queries
This is why Next.js Server Actions work beautifully here.

When NOT to Use Prisma with Supabase

❌ If you only need simple CRUD
❌ If you rely heavily on Supabase auto-generated APIs
❌ If you want RLS to handle all security

In these cases, Supabase client SDK alone may be enough.

When Prisma + Supabase Is a Power Combo

✅ Complex relational queries
✅ Non-trivial business logic
✅ Multi-tenant apps
✅ Admin dashboards
✅ Type safety across backend

This is where Prisma shines.

Performance & DX Benefits

Prisma gives compile-time safety
Supabase gives infra + auth
Next.js gives full-stack control

You avoid:

Raw SQL everywhere
Duplicate types
Unclear data ownership

Final Verdict

Supabase + Prisma is not redundant — it’s complementary.

Use Supabase as:

Infrastructure + Auth + Platform

Use Prisma as:

Your application’s data layer

Together with Next.js, this stack is:

scalable
maintainable
production-ready

Stop Using ngIf Like This — Angular’s @if, @for & @empty Are Cleaner

Mridu Dixit — Thu, 22 Jan 2026 12:08:17 +0000

Angular developers have used *ngIf and *ngFor for years. They work — but they also hide complexity, encourage messy templates, and become painful as UI logic grows.

Angular’s template control flow syntax (@if, @for, @empty, @switch) solves these problems with clear, explicit, and readable blocks.

If you’re still writing Angular templates the old way, this article shows why you should stop — and what to use instead.

**What’s Wrong with ngIf and ngFor?

The issue isn’t that they’re broken — it’s that they don’t scale well.

Common problems:

Hidden logic
Asterisk (*) magic that’s hard to reason about
Nested conditions become unreadable
Empty states require extra boilerplate

<div *ngIf="user; else loading">
  <app-profile [user]="user"></app-profile>
</div>

<ng-template #loading>
  <app-spinner></app-spinner>
</ng-template>

This works — but the logic is split across multiple places.

@if — Clear, Explicit Conditional Rendering

✅ Cleaner Alternative

@if (user) {
  <app-profile [user]="user"></app-profile>
} @else {
  <app-spinner></app-spinner>
}

Why this is better:

No
No indirection
Reads like real control flow
Easy to extend and refactor

Nested conditions also stay readable:

@if (user) {
  @if (user.isAdmin) {
    <admin-panel />
  } @else {
    <user-dashboard />
  }
}

*@for — A Better ngFor

❌ Old Way

<li *ngFor="let item of items; trackBy: trackById">
  {{ item.name }}
</li>

✅ New Way

@for (item of items; track item.id) {
  <li>{{ item.name }}</li>
}

Built-in variables are explicit and intuitive:

@for (item of items; let i = $index) {
  <p>{{ i + 1 }}. {{ item.name }}</p>
}

Available variables:

$index
$count
$first
$last
$even
$odd

@empty — No More Manual Empty State Checks

This is where Angular really shines.

❌ Old Pattern

<ul *ngIf="items.length > 0; else empty">
  <li *ngFor="let item of items">{{ item }}</li>
</ul>

<ng-template #empty>
  No items found
</ng-template>

✅ New Pattern

@for (item of items) {
  <li>{{ item }}</li>
} @empty {
  <li>No items found</li>
}

Why @empty is a big win:

No extra conditions
Empty state stays next to the list
Perfect for tables, dropdowns, dashboards

@switch — Readable State-Based UI

❌ Old ngSwitch

<div [ngSwitch]="status">
  <p *ngSwitchCase="'loading'">Loading...</p>
  <p *ngSwitchCase="'success'">Success</p>
  <p *ngSwitchDefault>Error</p>
</div>

✅ New Control Flow

@switch (status) {
  @case ('loading') {
    <p>Loading...</p>
  }
  @case ('success') {
    <p>Success</p>
  }
  @default {
    <p>Error</p>
  }
}

This reads exactly how it behaves.

Works Perfectly with Signals

items = signal<string[]>([]);

@for (item of items()) {
  <p>{{ item }}</p>
} @empty {
  <p>No data available</p>
}

No subscriptions.
No async pipe noise.
Angular handles reactivity automatically.

Performance & Maintainability Benefits

Angular’s control flow blocks:

Reduce unnecessary DOM nodes
Improve compile-time optimizations
Work seamlessly with zoneless Angular
Make templates easier to test and review This is not just syntax sugar — it’s better architecture.

*Should You Stop Using ngIf Completely?

No — existing code is fine.

But for:

New components
New features
Signal-based state
Complex UI logic

👉 @if, @for, and @empty should be your default choice

Final Thoughts

*ngIf and *ngFor were great — but Angular templates have moved on.

If you care about:

clean templates
readable UI logic
scalable Angular apps

then it’s time to stop using *ngIf like it’s 2018 and start writing templates the modern Angular way.

Zoneless Angular Explained — How Change Detection Works Without Zone.js

Mridu Dixit — Fri, 09 Jan 2026 18:06:14 +0000

For years, Angular relied on Zone.js to automatically trigger change detection. It worked—but it also made performance unpredictable and debugging harder.

With modern Angular, especially alongside Signals, Angular can now run without Zone.js.

This article explains:

what Zone.js actually did
how Angular works without it
what triggers change detection now
when you should (and shouldn’t) go zoneless

What Zone.js Did in Angular

Zone.js monkey-patches async APIs like:

setTimeout
Promise
fetch
DOM events

Whenever anything async happened, Angular would:
👉 re-run change detection for the entire component tree.

Result:

✔ UI always stayed in sync
❌ Too many unnecessary checks
❌ Hard to control performance
❌ “Why did my component re-render?” moments

The Problem with Zone-Based Change Detection

With Zone.js:

Any async event can trigger CD
Even unrelated components re-check
Performance tuning becomes guesswork

This was fine for small apps—but large apps paid the price.

What Is Zoneless Angular?

Zoneless Angular means:

Angular does not automatically run change detection on async events.

Instead, you explicitly tell Angular when state changes.
No magic.
No global re-checks.
Full control.

How Change Detection Works Without Zone.js

🔑 Key Concept

Change detection runs only when Angular knows data has changed.

This happens via:

Signals
Input changes
Explicit triggers

Signals: The Backbone of Zoneless Angular

Example: Signal-based state

count = signal(0);

increment() {
  this.count.update(v => v + 1);
}

Template:

<button (click)="increment()">+</button>
<p>Count: {{ count() }}</p>

What happens?

Signal updates
Angular knows exactly what changed
Only dependent views re-render ✔ No global change detection ✔ No Zone.js involved

Computed Signals (Derived State)

doubleCount = computed(() => this.count() * 2);

Angular tracks dependencies automatically.

Only affected templates update — nothing else.

Effects (Side Effects Without Zone)

effect(() => {
  console.log('Count changed:', this.count());
});

Used for:

logging
analytics
syncing storage
triggering API calls

What About Async Operations?

❌ Old Zone-based approach

setTimeout(() => {
  this.value = 10;
}, 1000);

Angular had to guess when to update UI.

✅ Zoneless Approach

value = signal(0);

setTimeout(() => {
  this.value.set(10);
}, 1000);

Signal update → Angular reacts → UI updates.

Running Angular Without Zone.js

Bootstrap example:

bootstrapApplication(AppComponent, {
  providers: [
    provideZoneChangeDetection({
      eventCoalescing: true,
      runCoalescing: true
    })
  ]
});

To fully remove Zone.js:

Remove zone.js import
Use signals & explicit triggers

What Still Triggers Change Detection?

Even without Zone.js:

Signal updates
Input bindings
Event handlers
Manual ChangeDetectorRef calls Angular stays reactive — just not automatic everywhere.

When Zoneless Angular Shines

✅ Large applications
✅ Performance-critical UIs
✅ Apps using Signals heavily
✅ Teams that want predictability

When NOT to Go Zoneless (Yet)

⚠ Legacy apps with heavy RxJS
⚠ Apps relying on implicit async updates
⚠ Teams not ready to refactor state logic

Zoneless is opt-in, not mandatory.

Zoneless + Signals = Predictable Angular

This combo gives Angular:

deterministic rendering
fewer re-renders
easier performance debugging
modern reactive mental model

Angular becomes:

“Update only what changed — nothing else.”

Final Thoughts

Zoneless Angular is not about removing features — it’s about removing guesswork.

Zone.js = automatic but noisy
Zoneless + Signals = explicit and fast

You don’t need to go zoneless everywhere—but understanding it makes you a better Angular developer.

Angular 21 — What’s New, What’s Changed

Mridu Dixit — Tue, 30 Dec 2025 06:59:30 +0000

Angular 21 focuses on simplification, performance, and modern reactive patterns. Instead of adding flashy APIs, it strengthens what Angular developers already use daily.

Let’s explore Angular 21 features with practical examples so you can immediately apply them.

1. Standalone Components by Default (No NgModules)

❌ Old Way (NgModule-based)

@NgModule({
  declarations: [UserComponent],
  imports: [CommonModule],
})
export class UserModule {}

✅ Angular 21 Way (Standalone)

@Component({
  selector: 'app-user',
  standalone: true,
  imports: [CommonModule],
  template: `<h2>User Works!</h2>`
})
export class UserComponent {}

✅ Benefits

Less boilerplate
Clear dependencies
Easier lazy loading

2. Signals for State Management (Simple & Predictable)

❌ Before (RxJS for simple state)

user$ = new BehaviorSubject<User | null>(null);

✅ Angular 21 Signals

user = signal<User | null>(null);

setUser(data: User) {
  this.user.set(data);
}

Using it in template:

<div *ngIf="user()">
  Welcome {{ user()?.name }}
</div>

➡️ No subscriptions. No memory leaks. Clean reactivity.

3. Computed Signals (Derived State)

firstName = signal('Mridu');
lastName = signal('Dixit');

fullName = computed(() => `${this.firstName()} ${this.lastName()}`);

<h3>{{ fullName() }}</h3>

➡️ Angular automatically recalculates when dependencies change.

4. Effect API (Reacting to Changes)

effect(() => {
  console.log('User changed:', this.user());
});

Use cases:

Analytics tracking
API calls
Logging
Syncing localStorage

5. Zoneless Angular (Better Performance)

Angular 21 makes Zone.js optional.

Enable zoneless mode:

bootstrapApplication(AppComponent, {
  providers: [provideZoneChangeDetection({ eventCoalescing: true })]
});

Result:

Faster change detection
More predictable updates
Signals + zoneless = 🔥

6. Faster Builds with esbuild (Under the Hood)

You don’t configure this manually — Angular CLI handles it.

What you’ll notice:

Faster ng serve
Faster rebuilds
Lower memory usage

Especially noticeable in large projects.

7. Improved SSR & Hydration (Less Pain)

Server Component Example:

@Component({
  standalone: true,
  template: `<p>Data loaded on server</p>`
})
export class ServerOnlyComponent {}

Angular 21 improves:

Hydration mismatch handling
Async data consistency
Debugging experience

Result → more reliable SSR apps.

8. Better Dependency Injection with Standalone Apps

Global provider:

bootstrapApplication(AppComponent, {
  providers: [provideHttpClient()]
});

Component-level provider:

@Component({
  standalone: true,
  providers: [UserService]
})
export class UserComponent {}

➡️ Clear scope, fewer surprises.

9. Stronger Template Type Safety

Angular catches this at build time:

<p>{{ user.nonExistingProp }}</p>

✔ No more silent runtime bugs
✔ Better IDE autocomplete
✔ Safer refactors

10. Migration Is Smooth (No Breaking Shock)

Angular 21 supports:

Existing RxJS code
NgModules (still supported)
Incremental migration to signals

You don’t have to rewrite everything.

Who Should Use Angular 21?

✅ New Angular projects
✅ Apps already using standalone components
✅ Performance-sensitive apps
✅ Teams tired of overusing RxJS for simple state

Final Thoughts

Angular 21 is about clarity and confidence:

Standalone-first architecture
Signals for state
Zoneless performance
Faster builds
Cleaner mental model

Angular is no longer “heavy” — it’s modern, reactive, and production-ready.

Webpack vs Vite in Angular — Which One Really Wins?

Mridu Dixit — Wed, 17 Dec 2025 04:41:26 +0000

Angular has traditionally relied on Webpack under the hood, but with Vite rapidly gaining popularity across the frontend ecosystem, many Angular developers are asking:

👉 Should I stick with Webpack, or is Vite a better choice for Angular projects?

Let’s break it down honestly, practically, and without hype.

What Is Webpack in Angular?

Webpack has been Angular’s default bundler for years through Angular CLI.

✅ Strengths

Deep integration with Angular CLI
Mature, stable, and battle-tested
Full control over build and optimization pipeline
Excellent support for SSR, i18n, and advanced builds

❌ Pain Points

Slower cold starts for large applications
Complex configuration
High memory usage
Hard to customize without ejecting

What Is Vite — and Why Developers Love It

Vite is a modern build tool built around:

Native ES modules
esbuild for lightning-fast bundling
A dev server that avoids bundling during development

🚀 Why Vite Feels Fast

Instant dev server startup
On-demand module loading
Extremely fast Hot Module Replacement (HMR)

Angular + Vite: Current Reality

Angular does not officially replace Webpack with Vite.

However, Angular has adopted:

esbuild for faster builds
A Vite-like development experience
Community-driven Vite integrations (experimental)

👉 Angular CLI still relies on Webpack for production builds, SSR, and advanced features.

Developer Experience Comparison

Feature Webpack (Angular CLI) Vite
Dev server startup Slow Instant
Hot reload Decent Extremely fast
Configuration Complex Minimal
Angular compatibility Native Experimental
SSR support Stable Limited
Ecosystem Very mature Rapidly growing

Build & Optimization

🔧 Webpack

Strong optimization and tree-shaking
Predictable production builds
Advanced code-splitting

⚡ Vite

Faster builds via esbuild
Simple configuration
Limited deep Angular optimizations

SSR & Enterprise Use Cases

If your Angular application relies on:

Server-Side Rendering
Internationalization
Large monorepos
Complex build pipelines

👉 Webpack remains the safest and most reliable choice.

Should Angular Developers Use Vite?

✅ Choose Webpack if:

You’re building production-grade Angular apps
You need SSR or advanced Angular CLI features
Stability and long-term support matter

🚀 Choose Vite if:

You’re prototyping or experimenting
You value fast feedback loops
Your app is relatively small
You’re comfortable with experimental tooling

The Real Takeaway

Webpack is still the backbone of Angular builds
Vite delivers an unmatched developer experience
Angular is clearly moving toward faster, simpler tooling inspired by Vite

Webpack powers Angular today.
Vite shapes how Angular tooling is evolving.

Final Thoughts

Both tools are excellent—but they solve different problems.

Until Angular officially adopts Vite end-to-end, Webpack remains the default and safest option, while Vite shines for experimentation and speed.

Top 10 API Call Security Mistakes Developers Still Make in 2025

Mridu Dixit — Wed, 10 Dec 2025 12:29:08 +0000

Introduction

Even in 2025, API call security remains one of the biggest weaknesses in modern applications. With more frontend-heavy apps, more third-party integrations, and more public APIs, developers are still repeating the same mistakes—leading to data leaks, token theft, and full application compromise.

Here are the top 10 API call security mistakes developers still make in 2025, and how to fix them.

1. Exposing API Keys in Frontend Code

Yes, it still happens.

Publishing API keys inside:
Angular/React source code
environment.ts files
mobile builds (APK/IPA)

…makes them accessible to anyone.

✅ Fix:

Never trust frontend to hide secrets
Move sensitive calls to a backend or Cloud Function proxy
Use restricted API keys with domain-level rules

2. Using Only Client-Side Validation

Client-side validation is easily bypassed with:

Postman
cURL
Browser network tab edits Relying on frontend checks leaves the backend wide open.

✅ Fix:

Perform all critical validation on the server (auth, role checks, payload checks).

3. Missing Proper Authentication (Tokenless API Calls)

Some developers still allow API endpoints to be accessed without:

JWT
OAuth2 token
API key
Session cookie

This leads to data leaking in minutes.

✅ Fix:

Enforce auth on every request.
No public endpoints unless explicitly intended.

4. Storing JWT Access Tokens in LocalStorage

Storing tokens in localStorage is still a major attack vector.

Reason:
If the site gets an XSS, attackers steal the token instantly.

✅ Fix:

Use:

HttpOnly cookies for access/refresh tokens
Short-lived tokens
Token rotation

5. Not Implementing Rate Limiting

Hackers abuse APIs by:

Brute forcing logins
Sending 10k requests per second
Enumerating users
Without rate limits, your APIs burn quickly.

✅ Fix:

Enable rate limiting at:

API Gateway
Cloudflare/WAF
Backend server

6. No Authorization Checks (Role / Permission Validation)

Many APIs authenticate users but never check permissions.

Examples:

User A can access User B’s data
Non-admins calling admin APIs
Direct object reference (IDOR) attacks

✅ Fix:

Always validate:

Role
Permissions
Resource ownership
1. Passing Sensitive Data Without Encryption Sending passwords, tokens, or personal data over non-HTTPS is a disaster.

Yes—developers still do it in dev/staging.

✅ Fix:

nforce HTTPS
Use HSTS
Reject mixed content

8. Not Validating Request Payloads

Hackers send:

Extra fields
Missing fields
Malicious JSON
Overly large payloads

Without schema validation, your API breaks or leaks data.

✅ Fix:

Use:

Zod / Yup
Joi
JSON schema
Validation pipes (NestJS)
1. Overly Verbose Error Messages Returning errors like:

User not found in DB table users_master

JWT expired at 2025-01-20T10:32:18Z

leaks internal logic to attackers.

✅ Fix:

Send generic safe responses:

Invalid credentials.

Log detailed errors on backend only.

10. No Logging & Monitoring

Developers often don’t track:

Failed requests
Suspicious API activity
Repeated auth failures
Sudden traffic spikes
This lets attackers run unchecked.

✅ Fix:

Use:

Firebase Monitoring
Cloud Logging
ELK / Datadog
Alerts for unusual API patterns

Conclusion

API security is no longer optional—it's a survival requirement in 2025.
Avoiding these 10 mistakes will make your applications safer, harder to attack, and more reliable.

Top 10 Mistakes Developers Still Make with Firebase in 2025

Mridu Dixit — Wed, 26 Nov 2025 12:38:19 +0000

Even in 2025, Firebase remains one of the most popular platforms for building real-time, serverless, and scalable applications. But with ease of use comes a new wave of misconfigurations, billing shocks, and performance issues—mostly caused by small but critical mistakes.

Here are the 10 most common Firebase mistakes developers still make in 2025—and how to avoid them.

1. Treating Firestore Like a SQL Database

Firestore is a NoSQL document DB. Developers still try to:

store highly relational data
perform “joins” inside documents
nest deeply structured objects
run many small reads instead of one optimized read

Fix:
Design for documents & collections. Prefer flatter structures and denormalize when it improves read efficiency.

2. Overusing Realtime Listeners Everywhere

Many apps subscribe to:

entire collections
large documents
listeners that run even when screens are hidden

This results in:

battery drain (mobile)
unnecessary read costs
re-renders in frontend frameworks

Fix:
Use .get() for static pages. Add listeners only where real-time matters.

3. Ignoring Firestore Indexes Until Production

2025, and devs still discover index errors… in production.

Symptoms:

queries suddenly fail
slow Firestore performance
Cloud Functions time out on complex queries

Fix:
Review the index suggestions in the Firebase Console early. Create composite indexes proactively.

4. Weak or Nonexistent Firebase Security Rules

Mistake: Opening security rules to public during development and forgetting to lock them later:

// ⚠️ Danger
allow read, write: if true;

Common vulnerabilities:

clients can overwrite documents
access documents from other tenants
delete entire collections Fix: Follow “least privilege” and test rules using Firebase Emulator Suite.

5. Storing Too Much in a Single Document

Firestore documents have limits:

1 MB per document
Write rate: 1 write per second per document

Mistake: Storing large arrays, logs, chats, or full history in one big doc.

Fix:
Break large data into subcollections. Store lists as paginated documents.

6. Forgetting About Cold Starts in Cloud Functions

Even in 2025, cold starts exist—especially on free tier or low-traffic functions.

Mistakes:

packaging too many dependencies
deploying many small functions
running heavy initialization code

Fix:
Use 1–5 grouped functions per region. Switch to 2nd Gen Cloud Functions (faster scaling + fewer cold starts).

7. Using Admin SDK Logic on Client Side

Unexpected but common issue:
Developers leak sensitive logic in frontend apps.

Examples:

verifying tokens on client
writing data with elevated privileges
performing restricted queries from browser/mobile

Fix:
Admin SDK should only run on secure environments like:

Cloud Functions
server backend
Admin panel with validated sessions

8. Not Leveraging Firestore’s Local Cache

Firestore has a powerful built-in cache for offline support. But:

many disable it
reload UI before cache hydrates
run duplicate network requests

Fix:
Enable caching (default ON), and design UI to read cached data instantly.

9. Incorrect Environment Handling (Web, Angular, React)

2025 mistake: Hardcoding Firebase config in frontend bundles—or storing prod config in dev environments.

Typical issues:

misconfigured API keys
SSR builds leaking env variables
staging accidentally pointing to production

Fix:
Use:

Angular: runtime environments (app.config.ts + external JSON)
React/Next.js: server-side env + runtime config
Set separate Firebase projects for dev/stage/prod

10. Not Monitoring Quotas & Billing
Firestore and Firebase are deceptively simple—but cost can explode fast due to:

chat apps
real-time listeners
large collections
over-triggered functions

Fix:
Use Firebase’s:

Usage dashboard
Cost explorer
Alerts for reads/writes/functions

Always set a budget alert early.

🧠 Final Thoughts

Firebase is powerful, scalable, and developer-friendly—but only when used correctly. A few small configuration mistakes can lead to huge performance problems or billing surprises.

Avoiding these 10 mistakes will help keep your Firebase applications fast, secure, and cost-efficient in 2025.

🧱 SSR vs SSG vs ISR: Choosing the Right Rendering Strategy in 2025

Mridu Dixit — Wed, 19 Nov 2025 04:36:38 +0000

The web in 2025 is faster, smarter, and more dynamic than ever. But how your app renders still determines whether users stay or bounce. Let’s decode SSR, SSG, and ISR — and which one truly wins today.

⚡ 1. Server-Side Rendering (SSR)

SSR generates HTML on-demand for every request. Frameworks like Next.js, Angular Universal, and Nuxt.js shine here.

✅ Pros:

SEO-friendly and fast first paint.

Always delivers the latest data.

❌ Cons:

Heavier server load.

Slower on repeated requests.

🧩 Example (Next.js):

export async function getServerSideProps() {
  const data = await fetchAPI();
  return { props: { data } };
}

⚙️ 2. Static Site Generation (SSG)

SSG builds pages once at build time — lightning-fast delivery with CDN caching.

✅ Pros:

Instant page loads.

Super cost-effective and scalable.

❌ Cons:

Data becomes stale until rebuild.

🧩 Example:

export async function getStaticProps() {
  const posts = await fetchPosts();
  return { props: { posts } };
}

🔄 3. Incremental Static Regeneration (ISR)

ISR is the hybrid approach — it combines SSG’s speed with SSR’s freshness by rebuilding pages in the background.

✅ Pros:

Near real-time updates.

Great balance of performance and data accuracy.

🧩 Example:

export async function getStaticProps() {
  const posts = await fetchPosts();
  return {
    props: { posts },
    revalidate: 60, // Rebuild every 60s
  };
}

🚀 Which Should You Choose in 2025?

Feature SSR SSG ISR
Speed ⚡⚡ ⚡⚡⚡ ⚡⚡⚡
Fresh Data ✅ Always ❌ On rebuild ✅ Periodically
Scalability ⚡ ⚡⚡⚡ ⚡⚡
Use Case Dynamic dashboards Blogs/docs E-commerce,hybrid apps

🧠 Final Takeaway

In 2025, ISR is the sweet spot — it gives you the speed of SSG with the freshness of SSR.
For pure static content, go SSG.
For real-time dashboards, choose SSR.
But if you want both — ISR is your best friend.