DEV Community: Kafeel Ahmad

Building a Simple REST API with Express.js — The Right Way

Kafeel Ahmad — Thu, 05 Feb 2026 16:20:30 +0000

Most Node.js developers start with Express when learning backend development. But even experienced devs often overlook key architectural decisions that impact scalability, maintainability, and security.

Today, we'll walk through building a clean, modular REST API using Express.js, covering:

API structure
Routing
Controllers
Middlewares
Error handling
Environment configs

🧱 Project Structure

Start with a clean structure:

project-root/
├── controllers/
├── routes/
├── middlewares/
├── models/
├── config/
├── utils/
├── app.js
└── server.js

This modular setup scales well for growing apps.

🧪 Step-by-Step: Create a Simple API

1. Install Express

npm init -y
npm install express dotenv

2. Create `server.js`

const app = require('./app');
const PORT = process.env.PORT || 5000;

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

3. Create `app.js`

const express = require('express');
const app = express();
const userRoutes = require('./routes/userRoutes');

app.use(express.json());
app.use('/api/users', userRoutes);
// Global error handler
app.use((err, req, res, next) => {
  res.status(err.status || 500).json({ message: err.message });
});
module.exports = app;

4. Add a Controller (`controllers/userController.js`)

exports.getAllUsers = (req, res) => {
  res.json([{ id: 1, name: 'Dipak' }]);
};

5. Add a Route (`routes/userRoutes.js`)

const express = require('express');
const router = express.Router();
const userController = require('../controllers/userController');

router.get('/', userController.getAllUsers);
module.exports = router;

🛡️ Add Environment Config

Create .env file:

PORT=5000
NODE_ENV=development

Install dotenv:

npm install dotenv

Load it in server.js:

require('dotenv').config();

🔒 Add Error Handling Middleware

In middlewares/errorHandler.js:

const errorHandler = (err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ message: 'Something went wrong!' });
};

module.exports = errorHandler;

And in app.js:

const errorHandler = require('./middlewares/errorHandler');
app.use(errorHandler);

📦 Bonus: Add CORS & Helmet for Security

npm install cors helmet
const cors = require('cors');
const helmet = require('helmet');

app.use(cors());
app.use(helmet());

✅ Final Output

Once set up, run your server:

node server.js

Visit: http://localhost:5000/api/users

You'll get:

[
  { "id": 1, "name": "Dipak" }
]

Clean, modular, and production-ready!

🔚 Final Thoughts

Building REST APIs in Node.js is simple — but doing it right requires planning.

Start clean, modularize your logic, and build secure endpoints. You're not just learning Express — you're becoming a better backend engineer.

Author: Dipak Ahirav

Node.js in 2026: Modern Practices You Should Be Using

Kafeel Ahmad — Fri, 09 Jan 2026 18:37:11 +0000

Node.js continues to be a powerhouse for backend JavaScript applications, but how we write Node apps in 2025 vastly differs from just a few years ago. With the evolving JavaScript ecosystem and rapid tooling innovations, sticking to old patterns can hold you back.

Here's a look at the modern Node.js practices you should use in 2025 to write cleaner, faster, and future-proof code.

1. ES Modules(ESM) First

In 2025, ES Modules are not just supported — they're the default.

Why It Matters:

ESM allows for better interop with modern JavaScript tools, supports top-level await, and aligns Node.js with browser-based module systems. It's time to ditch require and embrace import.

Best Practices:

Use .mjs file extensions or set "type": "module" In your package.json.
Prefer import/export syntax over require/module.exports.
Take advantage of top-level await to simplify async bootstrapping code.

// file name: app.mjs
import { express } from 'express';

const app = express();
app.use("/", (req, res)=>{
  res.send("Hello World");
});

2. Native `fetch` API Support

Node.js now ships with a native fetch() implementation, just like in the browser.

Why It Matters:

No more installing node-fetch. The global fetch() API is built-in and fully standards-compliant.

Best Practices:

Use fetch() for HTTP requests instead of legacy HTTP libraries unless you need low-level control.
Combine with AbortController for request timeouts and cancellations.

const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);

try {
  const res = await fetch('https://api.fakeapiexample.com/data', {
    signal: controller.signal
  });
  const data = await res.json();
  console.log(data);
} catch (err) {
  console.error('Error in request is: ', err);
}

3. Modern Testing with Vitest

The testing ecosystem has shifted. Jest is still relevant, but Vitest is the new favorite among developers working with modern JS and TypeScript.

Why It Matters:

Vitest is fast, supports ESM out of the box, has tight integration with Vite (though not required), and works seamlessly with TypeScript.

Best Practices:

Use Vitest for unit, integration, and component testing.
Leverage features like snapshot testing, mock support, and parallel test execution.

Install with:

npm install -D vitest

Run tests with:

npx vitest run

4. Bun Compatibility

Bun has emerged as a performance-focused alternative runtime for JavaScript and TypeScript. It's not a Node.js replacement (yet), but being Bun-compatible is quickly becoming a sign of a forward-thinking project.

Why It Matters:

Bun offers:

Blazing-fast runtime and tooling
Native TypeScript support
Built-in bundler, test runner, and package manager

Best Practices:

Ensure your project runs on both Node and Bun.
Avoid deep dependencies on Node-specific APIs unless necessary.
Use polyfills or abstraction layers when possible.

bun install
bun run index.ts

Bun is outstanding and useful for running lightweight servers, build tools, or CLIs.

5. TypeScript, Even for Small Projects

Zod can be used with Node.js for schema validations(Image Source: https://dev.to/osalumense/validating-request-data-in-expressjs-using-zod-a-comprehensive-guide-3a0j)

By now, TypeScript isn't just a "nice-to-have." It's standard for serious Node.js development.

Why It Matters:

TypeScript allows to definition of different types of variables, function parameters, and arguments, which indeed help the compiler catch type-related errors during the development phase and help developers coming from other languages to use a Strictly Typed language.

Although TypeScript will soon be using Golang inside the architecture, which will make it more fast and quick.

Best Practices:

Use tsconfig.json With strict mode enabled.
Prefer interfaces and types for function contracts and data models.
Combine with modern runtime validation tools zod for safe, typed I/O.

import { z } from 'zod';

const UserSchema = z.object({
  name: z.string(),
  age: z.number().min(18),
});

const input = { name: 'Alice', age: 25 };
const parsed = UserSchema.parse(input);

6. Dotenv is (Still) Your Friend — But Don't Hardcode

Managing configuration with .env Files are still valid, but pair them with validation tools and secrets managers in production.

Best Practices:

Use dotenv only in development or staging.
Validate config using libraries like env-var or zod.
Keep secrets out of version control.

import { config } from 'dotenv';
config();

import { cleanEnv, str, port } from 'envalid';

const env = cleanEnv(process.env, {
  NODE_ENV: str(),
  PORT: port({ default: 3000 }),
});

7. Zero-Config Dev Environments

Tools like tsx and nodemon have given way to simpler workflows. Prefer zero-config CLIs like:

tsx: Run TS files directly with ESM support.
bun:Directly runs .ts and .js with built-in TypeScript support.
nodemon: It helps to run .js file in the Node environment and helps in loading the app within milliseconds whenever we update the code.

With tsx:

npx tsx app.ts

With Nodemon:

nodemon app.js

8. Process Management with PM2: Keep Your Node App Alive

In production, your Node.js application needs to be resilient. Crashes, memory leaks, and restarts shouldn't bring your service down. PM2 (Process Manager 2) remains one of the most reliable tools for keeping your app alive and well-managed.

Why It Matters:

PM2 handles process restarts, monitoring, clustering, and log management with zero downtime. It's especially helpful when running apps outside containerized environments or on self-managed servers.

Best Practices:

Use PM2 to run and monitor your app in the background.
Enable clustering to take advantage of multi-core CPUs.
Use log rotation and process auto-restart features.

npm install -g pm2
pm2 start app.js --name my-app

Cluster Mode Example:

pm2 start app.js -i max

-i max: Spawns as many instances as CPU cores (uses Node.js cluster module under the hood).
View logs with pm2 logs.

PM2 also supports ecosystem configuration files and integrates with Docker and CI/CD pipelines.

Final Thoughts:

Node.js in 2025 is fast, modern, and cleaner than ever before — but only if you're keeping up. Embrace ES Modules, native APIs, and cutting-edge tools like Vitest and Bun. These practices won't just make your code better — they'll make you a more effective developer.

Whether you're building REST APIs, CLIs, or full-stack apps, the future of Node.js is modular, fast, and typed.

Great, you have reached the end. Thanks for Reading.

Author: Aryan Garg

Node.js Architecture Patterns for Scalable Apps (2026 Guide)

Kafeel Ahmad — Fri, 09 Jan 2026 18:31:15 +0000

Node.js has become the go-to choice for building high-performance, scalable apps — especially real-time systems, APIs, and microservices. But as your app grows in traffic and complexity, architecture matters more than ever. Without a proper structure, your codebase becomes a spaghetti mess, bugs multiply, and scaling feels impossible.

In this guide, we'll explore the best Node.js architecture patterns for 2026, explain when to use them, and provide simple examples so you can pick the right fit for your next big project.

Why Architecture Matters in Node.js

Node.js is built on a single-threaded, event-driven model. This makes it excellent for handling thousands of concurrent requests without heavy hardware. However:

Poor structure → Harder to maintain as teams grow
No separation of concerns → Slower development
Missing scalability strategy → App crashes under high traffic

Choosing the right architecture pattern ensures: ✅ Easy feature expansion ✅ High code maintainability ✅ Better fault tolerance ✅ Simple onboarding for new developers

1. Layered (Monolithic) Architecture

Best for: Small to medium apps, MVPs, startups with limited resources

This is the classic "all-in-one" pattern where all app logic (routes, controllers, services, database calls) lives in a single codebase.

Example Structure:

/app
  /controllers
  /models
  /routes
  /services
server.js

Example Route (Express.js):

// routes/userRoutes.js
const express = require('express');
const router = express.Router();
const userController = require('../controllers/userController');

router.get('/users', userController.getUsers);

module.exports = router;

// controllers/userController.js
const User = require('../models/User');
exports.getUsers = async (req, res) => {
  const users = await User.find();
  res.json(users);
};

Pros: Easy to start, simple deployment Cons: Harder to scale when traffic or code size grows

2. Microservices Architecture

Best for: Large-scale apps, SaaS products, systems with multiple teams

Microservices split your app into independent services (Auth, Payments, Notifications). Each service runs on its own process, database, and scaling strategy.

Example:

Auth Service: Manages user login/registration
Order Service: Handles transactions
Notification Service: Sends emails/SMS

// Example: Notification microservice

const express = require('express');

const app = express();

app.post('/send-email', (req, res) => {

  // Email sending logic

  res.send('Email sent!');

});

app.listen(4000, () => console.log('Notification Service running on port 4000'));

Services communicate via REST, gRPC, or message brokers (Kafka, RabbitMQ).

Pros: High scalability, independent deployments
Cons: More complex infrastructure and DevOps setup

3. Event-Driven Architecture

Best for: Real-time apps (chat, trading platforms, IoT, live dashboards)

Instead of calling services directly, components publish and subscribe to events.

Example:

User creates an order → Emits order_created event
Payment Service listens to order_created → Processes payment
Notification Service listens → Sends confirmation email

// Using Node.js EventEmitter

const EventEmitter = require('events');

const eventBus = new EventEmitter();

eventBus.on('order_created', (order) => {

  console.log(Order Received: <span class="hljs-subst">${order.id}</span>);

});

// Simulate event

eventBus.emit('order_created', { id: 123 });

Pros: Loosely coupled services, great for real-time apps
Cons: Harder debugging, requires message brokers at scale

4. Serverless Architecture

Best for: Startups, apps with unpredictable traffic, cost optimization

Instead of managing servers, you deploy functions (AWS Lambda, Azure Functions) that run on demand.

Example: AWS Lambda Function

exports.handler = async (event) => {

  const name = event.queryStringParameters.name || "Guest";

  return {

    statusCode: 200,

    body: JSON.stringify({ message: Hello, <span class="hljs-subst">${name}</span>! }),

  };

};

Pros: No server management, auto-scaling, pay-per-use
Cons: Cold starts, not ideal for high-frequency APIs

5. Clean / Hexagonal Architecture

Best for: Enterprise-grade apps, long-term maintainability

Separates business logic from frameworks, making it easier to swap databases, UI frameworks, or third-party APIs.

Example Layers:

Domain Layer: Business rules
Application Layer: Service orchestration
Infrastructure Layer: Database, API adapters

This ensures your core logic doesn't depend on Express or MongoDB — you can change tech stacks without rewriting everything.

Scaling Node.js Beyond Architecture

Even with the best architecture, scaling Node.js apps requires extra techniques:

Horizontal Scaling: Use PM2 or Kubernetes to run multiple Node.js instances
Caching: Redis or Memcached to reduce DB load
Load Balancing: Nginx, AWS ALB, or HAProxy
Database Optimization: Indexing, sharding, read replicas
Monitoring: Tools like Prometheus, Grafana, and New Relic

Final Thoughts

Node.js is a powerhouse for building high-traffic, real-time, and enterprise apps. Choosing the right architecture pattern in 2026 depends on your team size, app complexity, and scaling needs:

PatternBest ForLayered MonolithMVPs, StartupsMicroservicesLarge, Complex AppsEvent-DrivenReal-Time SystemsServerlessLow-maintenance, Cost-EffectiveClean/HexagonalEnterprise & Long-term Projects

If you're starting small, begin with Layered Architecture. As your user base grows, evolve into Microservices or Event-Driven systems.

Author: Somendradev

Domain-Driven Design (DDD) with Node.js: Best Practices for Large Projects

Kafeel Ahmad — Wed, 07 Jan 2026 18:11:37 +0000

Endless spaghetti code spread across controllers and services.
Business logic mixed with database queries.
Every bug fix breaking something completely unrelated.

That's where Domain-Driven Design (DDD) comes to the rescue.

DDD isn't just a fancy buzzword — it's a mindset and methodology for organizing complex software. In this post, I'll walk you through what DDD is, why it matters in Node.js projects, and how to implement it step by step with examples.

What is Domain-Driven Design (DDD)?

At its core, DDD is about:

Focusing on the business domain (the real-world problems your app solves).
Structuring your code around domain concepts (users, orders, payments) instead of technical layers.
Creating a shared language between developers and business stakeholders.
Instead of thinking in terms of controllers, services, repositories, you think in terms of domains, entities, and use cases.

Why Use DDD in Node.js?

Large Node.js projects often grow messy because of:
- Rapid feature additions.
- Too much logic in controllers.
- Mixed responsibilities.
DDD helps by: ✅ Keeping business logic clean and testable. ✅ Making it easier to scale your team — devs can own specific domains. ✅ Allowing future flexibility (swap DBs, frameworks, or message queues without rewriting core logic).

Core Building Blocks of DDD

Here are the main DDD concepts and how they translate into Node.js projects:
1. Entity → An object with identity (e.g., User, Order).
2. Value Object → Immutable data without identity (e.g., Email, Price).
3. Aggregate → A cluster of entities treated as one unit (e.g., Order with OrderItems).
4. Repository → Interface for data access (DB is an implementation detail).
5. Service / Use Case → Business logic operations (e.g., PlaceOrder).
6. Domain Events → Something that happened in the domain (e.g., OrderPlaced).
Node.js Project Structure with DDD

Here's how you might structure a DDD-inspired Node.js project:
```
src/
├── modules/
│    ├── users/
│    │    ├── domain/
│    │    │    ├── User.js
│    │    │    ├── Email.js
│    │    ├── application/
│    │    │    ├── RegisterUser.js
│    │    ├── infrastructure/
│    │    │    ├── MongoUserRepository.js
│    │    └── index.js
│    ├── orders/
│    │    ├── domain/
│    │    ├── application/
│    │    ├── infrastructure/
├── shared/
│    ├── domain/
│    └── utils/
```
Notice how each domain (like users, orders) has its own domain, application, and infrastructure layers.

Example: User Registration in DDD

1. Entity: User
```
// modules/users/domain/User.js
export class User {
constructor({ id, name, email }) {
this.id = id;
this.name = name;
this.email = email;
}
}
```
2. Value Object: Email
```
// modules/users/domain/Email.js
export class Email {
constructor(address) {
if (!address.includes("@")) throw new Error("Invalid email");
this.address = address;
}
}
```
3. Repository Interface
```
// modules/users/domain/UserRepository.js
export class UserRepository {
async save(user) {
throw new Error("Method not implemented");
}
```

async findByEmail(email) {
throw new Error("Method not implemented");
}
}

4. Application Service (Use Case): RegisterUser

// modules/users/application/RegisterUser.js

export class RegisterUser {

  constructor(userRepository) {

    this.userRepository = userRepository;

  }

async execute({ name, email }) {

    const existing = await this.userRepository.findByEmail(email);

    if (existing) throw new Error("User already exists");

<span class="hljs-keyword">const</span> user = { <span class="hljs-attr">id</span>: <span class="hljs-title class_">Date</span>.<span class="hljs-title function_">now</span>().<span class="hljs-title function_">toString</span>(), name, email };
<span class="hljs-keyword">await</span> <span class="hljs-variable language_">this</span>.<span class="hljs-property">userRepository</span>.<span class="hljs-title function_">save</span>(user);
<span class="hljs-keyword">return</span> user;


}

}

5. Infrastructure: MongoDB Repository Implementation

// modules/users/infrastructure/MongoUserRepository.js

import { UserRepository } from "../domain/UserRepository.js";

export class MongoUserRepository extends UserRepository {

  constructor(mongoClient) {

    super();

    this.collection = mongoClient.db().collection("users");

  }

async save(user) {

    await this.collection.insertOne(user);

  }

async findByEmail(email) {

    return await this.collection.findOne({ email });

  }

}

6. Connecting Everything

import express from "express";

import { MongoClient } from "mongodb";

import { MongoUserRepository } from "./modules/users/infrastructure/MongoUserRepository.js";

import { RegisterUser } from "./modules/users/application/RegisterUser.js";

async function main() {

  const app = express();

  app.use(express.json());

const mongo = new MongoClient("mongodb://localhost:27017");

  await mongo.connect();

const userRepository = new MongoUserRepository(mongo);

  const registerUser = new RegisterUser(userRepository);

app.post("/register", async (req, res) => {

    try {

      const user = await registerUser.execute(req.body);

      res.status(201).json(user);

    } catch (err) {

      res.status(400).json({ error: err.message });

    }

  });

app.listen(3000, () => console.log("Server running on port 3000"));

}

main();

Best Practices for DDD in Node.js

Keep domains independent → No direct calls between users and orders. Use events or application services.
Separate concerns → Business logic (domain) should not depend on infrastructure (DB, HTTP).
Use Value Objects generously → They enforce domain rules early.
Introduce Domain Events → Let domains communicate via events (UserRegistered, OrderPlaced).
Think in Ubiquitous Language → Name your classes, methods, and events in a way business folks understand.

Final Thoughts

Domain-Driven Design might feel like extra ceremony when you start, but for large projects, it's a lifesaver. You'll end up with:

Modular architecture that scales with teams.
Maintainable business logic that's testable and framework-agnostic.
Future-proof flexibility — swap Express, MongoDB, or Redis without touching core logic.

So next time you're kicking off a big Node.js project, try structuring it with DDD. It'll keep your codebase healthy for years to come.

Author: Somendradev

Building a Simple REST API with Express.js — The Right Way

Kafeel Ahmad — Wed, 07 Jan 2026 18:06:43 +0000

Today, we'll walk through building a clean, modular REST API using Express.js, covering:

API structure
Routing
Controllers
Middlewares
Error handling
Environment configs

Not a Member? Read for FREE here.

🧱 Project Structure

Start with a clean structure:

project-root/
├── controllers/
├── routes/
├── middlewares/
├── models/
├── config/
├── utils/
├── app.js
└── server.js

This modular setup scales well for growing apps.

🧪 Step-by-Step: Create a Simple API

1. Install Express

npm init -y
npm install express dotenv

2. Create `server.js`

const app = require('./app');
const PORT = process.env.PORT || 5000;

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

3. Create `app.js`

const express = require('express');
const app = express();
const userRoutes = require('./routes/userRoutes');

app.use(express.json());
app.use('/api/users', userRoutes);
// Global error handler
app.use((err, req, res, next) => {
  res.status(err.status || 500).json({ message: err.message });
});
module.exports = app;

4. Add a Controller (`controllers/userController.js`)

exports.getAllUsers = (req, res) => {
  res.json([{ id: 1, name: 'Dipak' }]);
};

5. Add a Route (`routes/userRoutes.js`)

const express = require('express');
const router = express.Router();
const userController = require('../controllers/userController');

router.get('/', userController.getAllUsers);
module.exports = router;

🛡️ Add Environment Config

Create .env file:

PORT=5000
NODE_ENV=development

Install dotenv:

npm install dotenv

Load it in server.js:

require('dotenv').config();

🔒 Add Error Handling Middleware

In middlewares/errorHandler.js:

const errorHandler = (err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ message: 'Something went wrong!' });
};

module.exports = errorHandler;

And in app.js:

const errorHandler = require('./middlewares/errorHandler');
app.use(errorHandler);

📦 Bonus: Add CORS & Helmet for Security

npm install cors helmet
const cors = require('cors');
const helmet = require('helmet');

app.use(cors());
app.use(helmet());

✅ Final Output

Once set up, run your server:

node server.js

Visit: http://localhost:5000/api/users

You'll get:

[
  { "id": 1, "name": "Dipak" }
]

Clean, modular, and production-ready!

🔚 Final Thoughts

Building REST APIs in Node.js is simple — but doing it right requires planning.

Start clean, modularize your logic, and build secure endpoints. You're not just learning Express — you're becoming a better backend engineer.

<a rel="noopener follow" href="https://blog.stackademic.com/can-you-optimize-node-js-streams-for-maximum-performance-c4e690bcf051">


            <h2>Can You Optimize Node.js Streams for Maximum Performance?</h2>

                <h3>Mastering Node.js streams: the secret to handling massive data efficiently without crashing your app.</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">stackademic.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/1*oOFYAyqNJmqqcwnI7-1Irw.png'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

Connect with Me

If you enjoyed this post and would like to stay updated with more content like this, feel free to connect with me on social media:

Twitter : Follow me on Twitter for quick tips and updates.
LinkedIn : Connect with me on LinkedIn
YouTube : Subscribe to my YouTube Channel for video tutorials and live coding sessions.
Dev.to : Follow me on Dev.to where I share more technical articles and insights.
WhatsApp : Join my WhatsApp group to get instant notifications and chat about the latest in tech

Email: Email me on dipaksahirav@gmail.com for any questions, collaborations, or just to say hi!

I appreciate your support and look forward to connecting with you!

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don't receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don't forget to clap and follow the writer️!

Author: Dipak Ahirav

How to Become a Pro in Node.js ( Roadmap for Serious Devs)

Kafeel Ahmad — Wed, 07 Jan 2026 18:04:46 +0000

Node.js is more than just JavaScript on the server. It powers everything from real-time apps to APIs, CLI tools, and microservices. But how do you go from "I use Express" to "I own the backend"?

Let's break it down — this is your step-by-step path to mastering Node.js like a pro. No fluff. All action. ⚙️

📍 Step 1: Master the Core Before You Touch Frameworks

Most devs jump straight to Express, but the real power lies in Node core modules.

✅ Understand these first:

http — build raw servers
fs — handle files and streams
path, url, querystring — for building real routes
events — build your own event-driven logic
buffer, process, os — dive deeper into system-level interaction

🧠 Pro Tip: Try building an HTTP server without Express.

📦 Step 2: Know the Module System Inside-Out

Understanding the difference between:

require() (CommonJS)
import (ES Modules)
module.exports vs exports.foo ...is critical for writing modular, scalable code.

Also, learn how package.json works

"main" field
"type": "module"
"scripts"
Semantic versioning rules (^1.0.0, ~1.0.0) 📁

🧵 Step 3: Understand the Event Loop & Asynchronous Nature

Node is non-blocking by default — but if you don't understand how it really works, you'll write blocking code anyway.

✅ Study:

The Call Stack, Event Loop, Callback Queue, Microtasks
process.nextTick() vs setImmediate()
Why await in a loop can be dangerous
Promise.all() vs Promise.allSettled()

📚 Use tools like node-clinic or the Chrome DevTools profiler for real practice.

⚙️ Step 4: Deep Dive into Express & Middleware

Express is a must, but become a power user, not a copy-paster.

✅ Learn:

How middleware works (including next())
Error-handling middlewares
Route grouping, param middleware
CORS, body parsing, rate limiting
Modular routing using Router()

🔥 Build your own mini Express clone to master the flow.

🧱 Step 5: Build Real APIs (REST + GraphQL)

Now apply what you know to actual API design:

✅ Learn:

REST conventions (GET, POST, PATCH, DELETE)
Pagination, filtering, sorting
Status codes (201, 204, 422, etc.)
Token-based auth (JWT)
API versioning (/v1/products)
Swagger/OpenAPI docs

🧠 Bonus: Explore GraphQL using Apollo Server or Mercurius

🛡️ Step 6: Learn Security Best Practices

Security makes you truly senior.

🔐 Learn to:

Sanitize input (express-validator, xss-clean)
Protect against SQL/NoSQL injection
Use HTTPS, CORS, and CSRF protection
Set secure cookies
Handle JWT refresh tokens properly
Prevent DOS attacks via rate limiting + helmet

🧰 Step 7: Work with Databases Like a Pro

Node works with any DB — but you should master:

✅ NoSQL:

MongoDB with mongoose
Aggregation pipelines
Schema design for scale

✅ SQL:

PostgreSQL/MySQL with sequelize or knex
Transactions
Joins and migrations

📌 Use tools like Prisma for full-stack workflows.

🪄 Step 8: Use Modern Dev Tools & Patterns

Professional Node apps use:

dotenv for config
pm2 for process management
winston or pino for logging
joi or zod for schema validation
Jest or Supertest for testing
Docker for containerization 🐳
GitHub Actions or Jenkins for CI/CD

🔁 Learn monorepo tools like nx, turbo, or lerna for large-scale projects.

🧵 Step 9: Explore Advanced Node Concepts

Once you're comfortable, dive deeper:

🚀 Learn:

worker_threads and parallel processing
child_process and shell scripts
cluster module for multi-core scaling
WebSockets with socket.io
Building CLI tools with commander.js or yargs
Rate limiting & caching with Redis
Message queues like RabbitMQ or BullMQ

🛠️ Step 10: Build Something Real

Apply everything by building a full project like:

📦 E-commerce backend
✈️ Booking API with payment
🧠 Chat app with socket.io
🔐 Auth system with email + social login
🚀 SaaS dashboard with user tiers

Push it to GitHub, deploy on Render, Railway, or Vercel, and start your portfolio.

🔁 Bonus: Join the Node.js Community

Star good repos on GitHub
Read Node.js RFCs and release notes
Join forums like Node.js Reddit, Discords, or Indie Hackers

💬 Final Word

🧠 You don't become a Node.js pro by reading tutorials.

✅ You become one by:

Breaking and fixing things
Asking why things work the way they do
Rebuilding pieces from scratch
Helping others and sharing your learnings

👊 You're not just a dev who knows Node. You're a backend problem solver.

Author: Amanda

How To Replace Over-Complicated NgRx Stores With Angular Signals — Without Losing Control

Kafeel Ahmad — Wed, 07 Jan 2026 18:01:03 +0000

Hey, picture this: you're knee-deep in an Angular app, drowning in NgRx actions, reducers, effects, and selectors just to flip a simple boolean, load some todos, or filter a list. It's battle-tested for massive enterprise beasts where every change needs auditing across huge teams, but for most real-world projects? It's total overkill — endless boilerplate files that steal your dev joy and slow you down.

Then Angular Signals burst onto the scene like a breath of fresh air. Native, lightweight reactivity that slashes 70% of that NgRx ceremony while making your app scream faster — no more Zone.js crutches or unpredictable re-renders. Signals track dependencies surgically, updating only what needs to change, and they're downright fun to use.

What if you could ditch NgRx entirely and build clean, scalable state right in injectable services? That's our mission here: a practical guide to migrating with update() for bulletproof immutable changes (spread those arrays and objects!), smart patterns for global state sharing, computed values that derive on-the-fly, and side effects that sync with localStorage or APIs without the drama. Skip the heavy NgRx SignalStore—we're going pure Signals for maximum simplicity and speed.

Whether you're a dev sick of verbosity, a tech lead craving happier teams that ship faster, or a stakeholder eyeing cheaper, zippier apps — this no-nonsense path delivers. Ready to reclaim your weekends? Let's dive in and make state management feel effortless again.

NgRx Pain Points and Signals Advantages

Let's get real: NgRx is like hiring a full construction crew to hang a single picture frame — it's powerhouse stuff for massive enterprise cathedrals, but for everyday apps like dashboards, e-commerce carts, or internal tools, it buries you under mountains of boilerplate that kill momentum. Signals flip that script entirely, delivering lightweight reactive magic that slashes ceremony, accelerates development, and turns maintenance into something humans actually enjoy — even for teams dodging RxJS rabbit holes.

Why NgRx Feels Like Overkill in Real-World Projects

Imagine kicking off a simple feature: a user counter for your analytics dashboard. NgRx demands the full Redux ritual — create counter.actions.ts with increment() and decrement() creators, craft counter.reducer.ts to immutably switch on those actions, define counter.state.ts interfaces, build counter.selectors.ts for peeking at state, then wire a feature module with StoreModule.forFeature(). That's 5-10 files minimum, hundreds of lines just to count clicks. New hires stare at the folder explosion, onboarding drags into weeks, and tweaking logic means hunting across a dozen spots ripe for copy-paste bugs. Reddit threads overflow with war stories: "Lost a full week mastering boilerplate for a basic todo list".

Non-enterprise reality? Startups and mid-sized teams crave velocity — this overhead murders it. Unit testing drowns in Store mocks and marble diagrams. Debugging? Good luck tracing dispatched actions through the Redux time machine. Small apps rarely need a god-store; local services suffice until regret hits at scale. No surprise savvy teams skip NgRx until truly forced, often never.

Signals Fundamentals: Reactive Primitives Anyone Can Grasp

Signals bring Angular's reactivity into the 21st century — simple primitives that pack a punch without RxJS esoterica. Kick off with signal(initialValue): wrap any data (primitives, objects, arrays) and Angular auto-tracks reads/writes for precise notifications. Update via set(newValue) for direct swaps, update(fn => transformedValue) for safe derivations—Angular figures out exactly what to refresh, no manual plumbing.

Next, computed(() => yourLogic()) crafts read-only derived state that smartly recalculates only when dependencies budge, caching aggressively to nix waste. Side effects? effect(() => { sideEffect(signalValue()) }) fires precisely on changes—log analytics, sync APIs, trigger animations—subscription-free, leak-proof, running in batched microtasks for silky smoothness. Glitches? Banished. The graph ensures consistent ordering. Managers love this: codebases shrink 50%+, bugs plummet, juniors ship Day 1 sans Redux seminary.

Scalability Showdown: Signals Leave NgRx in the Dust

NgRx leans on zone.js change detection — monkey-patching every async event to scan your entire app tree. Small apps? Tolerable. Scale to 100+ components? Sluggish repaint marathons. Signals unlock fine-grained reactivity: only dirty components re-render, turbocharging zoneless Angular (v16 experiments now v18 production). Benchmarks scream victory — 2–5x faster list renders, form updates, dashboard charts, especially on mobile.

Signals prioritize immutability via update(), birthing predictable fresh values—like signalArray.update(arr => [...arr, newItem]) for clean array growth. NgRx clings to RxJS streams and zone pollution; Signals scale fluidly from component locals to app-wide services, no Big Bang store refactor needed. Growing teams pivot seamlessly as complexity creeps in.

Hands-On Demo: Counter Face-Off That Converts Skeptics

Time to build: simple increment/decrement/reset counter. NgRx gauntlet? Architect a village:

counter.actions.ts: Action creators increment(), decrement()
counter.reducer.ts: Immutable switch returning new state slices
counter.state.ts: { count: number } interface
counter.selectors.ts: selectCount(state)
counter.module.ts: StoreModule.forFeature('counter', reducer)
Component boilerplate: store.dispatch(), store.select(), OnDestroy cleanup

300+ lines of ceremony, typo-prone indirection. Signals? One standalone component, pure bliss:

import { Component, signal, computed } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <h2>Count: {{ count() }} (Double: {{ double() }})</h2>
    <button (click)="increment()">+1</button>
    <button (click)="decrement()">-1</button>
    <button (click)="reset()">Reset</button>
  `,
})
export class CounterComponent {
  count = signal<number>(0);
  double = computed(() => this.count() * 2);

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

  decrement(): void {
    this.count.update((v: number) => v - 1);
  }

  reset(): void {
    this.count.set(0);
  }
}

Spot the revolution? Typed TypeScript bliss — IntelliSense dances, refactors fearless, compile-time guards halt bugs. Test? Invoke methods directly, mock nothing. Share via injectable service? provideIn: 'root'. Scales to carts, forms, auth without breaking sweat. Stakeholders beam at velocity; engineers celebrate simplicity. Ditch the sledgehammer—Signals are your scalpel.

Building a Signals-Based State Service

Imagine converting a basic Angular service into a reactive "signals store" — your app's smart command center. Group related signals, expose public readonly views, control private mutations. Ditch change detection headaches for precise, automatic updates. Perfect for todos, carts, dashboards. Let's build one, then a production todo app under 100 lines.

Why Signals Stores Win

Skip heavy libraries. Injectable services become lightweight stores: zero deps, pure Angular, fine-grained reactivity.

Managers: Less code, fewer bugs, faster apps. Devs: Toggle one item? Only that row repaints. Scales to enterprise.

Store Foundation (30 lines)

import { Injectable, signal, computed, effect } from '@angular/core';

export interface Todo {
  id: number;
  text: string;
  completed: boolean;
}

@Injectable({ providedIn: 'root' })
export class TodoStore {
  // Private state
  private _todos = signal<Todo[]>([]);
  private _filter = signal<'all'|'active'|'completed'>('all');
  private _loading = signal(false);
  // Public reads
  public readonly todos = this._todos.asReadonly();
  public readonly filter = this._filter.asReadonly();
  public readonly loading = this._loading.asReadonly();
  // Derived state
  public readonly filteredTodos = computed(() => {
    const f = this._filter();
    const todos = this._todos();
    return f === 'active' ? todos.filter(t => !t.completed) :
           f === 'completed' ? todos.filter(t => t.completed) : todos;
  });
  public readonly totalTodos = computed(() => this.todos().length);
  public readonly activeCount = computed(() => this.todos().filter(t => !t.completed).length);
  public readonly completedCount = computed(() => this.totalTodos() - this.activeCount());
}

Magic: Computeds only rerun when dependencies change.

Effects: Auto-Sync (5 lines)

constructor() {
  effect(() => {
    const todos = this._todos();
    if (todos.length) localStorage.setItem('todos', JSON.stringify(todos));
  });
}

Swaps easily for API calls.

CRUD: Immutable Only (40 lines)

addTodo(text: string): void {
  const trimmed = text?.trim();
  if (!trimmed) return;
  this._todos.update(todos => [...todos, {id: Date.now(), text: trimmed, completed: false}]);
}

toggleTodo(id: number): void {
  this._todos.update(todos => todos.map(t => 
    t.id === id ? {...t, completed: !t.completed} : t
  ));
}

editTodo(id: number, text: string): void {
  const trimmed = text?.trim();
  if (!trimmed) return;
  this._todos.update(todos => todos.map(t => 
    t.id === id ? {...t, text: trimmed} : t
  ));
}

removeTodo(id: number): void {
  this._todos.update(todos => todos.filter(t => t.id !== id));
}

setFilter(filter: 'all'|'active'|'completed'): void {
  this._filter.set(filter);
}

clearCompleted(): void {
  this._todos.set(this.todos().filter(t => !t.completed));
}

async loadTodos(): Promise<void> {
  this._loading.set(true);
  try {
    await new Promise(r => setTimeout(r, 800));
    const saved = localStorage.getItem('todos');
    if (saved) this._todos.set(JSON.parse(saved));
  } finally {
    this._loading.set(false);
  }
}

Key: Always return new arrays/objects. Reactivity guaranteed.

Complete Todo App

Reactive forms + modern templates. Logic: 25 lines.

import { Component, signal, inject } from '@angular/core';
import { FormControl, ReactiveFormsModule, Validators } from '@angular/forms';
import { CommonModule } from '@angular/common';
import { TodoStore, Todo } from './todo.store';

@Component({
  selector: 'app-todo',
  standalone: true,
  imports: [CommonModule, ReactiveFormsModule],
  template: `
    <main class="app">
      <header>
        <h1>Signal Todos</h1>
        <div>Total: {{store.totalTodos()}} | Active: {{store.activeCount()}}</div>
        
        @let loading = store.loading();
        @if (loading) { <div>⏳ Loading...</div> }
      </header>
      <form (ngSubmit)="addTodo()" class="add-form">
        <input [formControl]="newTodoCtrl" placeholder="New todo..." />
        <button type="submit" [disabled]="newTodoCtrl.invalid">Add</button>
      </form>
      <nav class="filters">
        @for (let f of filterOptions; track f) {
          <button [class.active]="store.filter() === f" (click)="store.setFilter(f)">
            {{f[0].toUpperCase() + f.slice(1)}}
          </button>
        }
      </nav>

      @let todos = store.filteredTodos();
      @if (todos.length) {
        <ul>
          @for (let todo of todos; track todo.id) {
            <li [class.done]="todo.completed">
              <input type="checkbox" [checked]="todo.completed" (change)="store.toggleTodo(todo.id)" />
              @if (!editingId() || editingId() !== todo.id) {
                <span (dblclick)="editTodo(todo)">{{todo.text}}</span>
              } @else {
                <input [formControl]="editCtrl" (keyup.enter)="saveEdit()" (blur)="saveEdit()" autofocus />
              }
              <button (click)="store.removeTodo(todo.id)">Delete</button>
            </li>
          }
        </ul>

        @let done = store.completedCount();
        @if (done) {
          <button (click)="store.clearCompleted()">Clear {{done}} done</button>
        }
      } @else {
        <p>No {{store.filter()}} todos</p>
      }
    </main>
  `,
  styles: [`
    .app { max-width: 600px; margin: 2rem auto; padding: 1rem; }
    .add-form { display: flex; gap: 1rem; margin: 2rem 0; }
    .filters { display: flex; gap: 0.5rem; justify-content: center; margin: 2rem 0; }
    .filters button.active { background: #3b82f6; color: white; }
    li { display: flex; gap: 1rem; align-items: center; padding: 1rem; border: 1px solid #eee; }
    li.done { opacity: 0.6; text-decoration: line-through; }
  `]
})
export class TodoComponent {
  protected store = inject(TodoStore);
  protected newTodoCtrl = new FormControl('', Validators.required);
  protected editCtrl = new FormControl('');
  protected editingId = signal<number | null>(null);
  protected filterOptions = ['all', 'active', 'completed'] as const;

  constructor() {
    this.store.loadTodos();
  }

  addTodo(): void {
    const text = this.newTodoCtrl.value?.trim();
    if (text) {
      this.store.addTodo(text);
      this.newTodoCtrl.reset();
    }
  }

  editTodo(todo: Todo): void {
    this.editingId.set(todo.id);
    this.editCtrl.setValue(todo.text);
  }

  saveEdit(): void {
    const id = this.editingId();
    const text = this.editCtrl.value?.trim();
    if (id && text) this.store.editTodo(id, text);
    this.editingId.set(null);
    this.editCtrl.reset();
  }
}

The Power Unleashed

85-line service + 25-line component = production todo app with:

✅ Full CRUD operations
✅ Smart filtering
✅ LocalStorage sync
✅ Loading states
✅ Inline editing
✅ Bulk actions
✅ Form validation
✅ Modern Angular 18+ (@for/@if, signals)

Scale it: Shopping carts? User profiles? Analytics? Same pattern. Immutable updates + computed derivations = unbeatable performance.

Signals stores = simple, reactive, scalable. Your new Angular default.

Migration Strategy from NgRx to Signals

Hey folks, let's dive into migrating from NgRx to Angular Signals. Everyone's buzzing about Signals because they make state management way simpler and faster — no more drowning in actions, reducers, and endless selector chains. The beauty is you don't have to burn your NgRx setup to the ground. Start small with UI state like toggles and forms, keep NgRx for the heavy global stuff like user auth, and gradually shift over. It's less scary than it sounds, and your app gets noticeably snappier along the way.

Step-by-Step Refactor Process

First up, grab a coffee and map out your state. Ask yourself: is this dialog open state local to one component, or does it need to sync across the whole app? Local stuff screams for Signals. Global (think shared product catalogs) — leave it with NgRx for now.

Next, tackle those selectors. Instead of store.select(selectCart) | async everywhere, use NgRx's own selectSignal() wrapped in a computed(). Ditch the async pipes – your templates breathe again. Then swap actions for service methods. Imagine dispatch(addToCart(item)) becomes cartService.add(item) with a clean this.cart.update(items => [...items, item]).

Here's how I'd tackle it over a few sprints:

Audit your state: Local = Signals. Global = NgRx. Use Nx dependency graphs or just grep your codebase.
Selectors first: readonly cartItems = this.store.selectSignal(selectCartItems); – done, use cartItems() everywhere.
Actions to methods: Create injectable services as the single source of truth. Test one feature at a time.
Verify with Profiler: Angular DevTools shows render wins immediately. Feature flag everything.
Rinse and repeat: One lazy-loaded module per week. Ship, celebrate, move on.

I love how each step peels back NgRx ceremony you didn't really need. Suddenly your components are half the size.

The Smart Hybrid Approach

Look, NgRx is battle-tested for crazy complex flows — optimistic updates, cross-tab sync, effects with retries. Don't fight it. Let NgRx own global state, Signals handle everything else. Your renders speed up 2–3x because Signals trigger exactly what's needed, no Zone.js wakeups.

Here's the real-world breakdown:

NgRx vs Signals

Teams mixing both report the best results — NgRx for orchestration, Signals for reactivity. Shopping apps keep order history global, cart UI local. Perfect balance.

Keeping Control with Unidirectional Flow

Chaos happens when every component pokes at shared state. Solution? Route everything through services. CartService becomes your gatekeeper: add(item), remove(id), clear(). Want to debounce rapid adds from some legacy Effect? toObservable(this.cart).pipe(debounceTime(300), takeUntilDestroyed()).subscribe(...). Boom – RxJS and Signals play nice.

Steal this service pattern:

@Injectable({providedIn: 'root'})
export class CartService {
  readonly cart = signal<Item[]>([]);
  
  add(item: Item): void {
    this.cart.update(items => [...items, item]);
  }
  
  // Bridge old effects
  constructor() {
    toObservable(this.cart)
      .pipe(debounceTime(250), takeUntilDestroyed())
      .subscribe(items => this.saveToLocalStorage(items));
  }
}

Add a lint rule: "no direct signal updates outside services." Team stays sane, data flows one way.

Real-World Test: Shopping Cart Migration

Nothing proves this like a shopping cart refactor — everyone has one, and the wins are dramatic. Rip out the NgRx feature module. Build CartService with cartItems = signal([]).

Template goes from this mess:

<p>Total: {{ cart$ | async | currency }}</p>
@for (item of cart$ | async; track item.id) { ... }

To pure bliss:

<p>Total: {{ cartItems().reduce((sum, i) => sum + i.price, 0) | currency }}</p>
@for (item of cartItems(); track item.id) { ... }
<button (click)="cartService.add(item)">Add</button>

Fire up Angular Profiler:

Renders: 2x faster. Signals skip unchanged DOM.
Bundle: -15KB. No more NgRx feature bloat.
Memory: Fewer subscriptions = happier GC.

Feature flag it: @if (useSignalsCart()) { <signal-cart /> }. A/B test Time to Interactive with real traffic. Users notice the cart feels instant. Green light? Hit wishlist next, then user settings. By checkout, half your app runs on Signals, zero outages.

This isn't some pipe dream — teams shipping this weekly. Start with that cart tomorrow. You'll wonder why you waited.

Conclusion

So there you have it — Angular Signals are your new best friend when it comes to ditching that overwhelming pile of NgRx boilerplate so many apps wrestle with.

Picture this: a single, elegant update() call lets you handle immutable state changes—like incrementing a counter or patching user data—without breaking a sweat. Everything flows predictably through lightweight, injectable services, no more chasing side effects or debugging reducer chains.

Best part? You're perfectly positioned for Angular's full-on shift to reactivity, where signals power fine-grained updates and blazing performance. Honestly, for about 80% of projects, this switch means way less code, fewer late-night bugs, and templates that just… work, skipping the whole action-reducer-effect tango.

Ready to jump in hands-on?

Grab the AngularSpace article packed with migration examples, snag your app's simplest store (basic counter or todo list), and refactor it with update() magic. Test the waters, clock those performance gains (often 50% less code, zero downsides), and drop your before/after stories right here in the comments.

Deep dive time:

Swing by Angular's official Signals docs to master computed() and effect(). Check NgRx's v21 migration guide for smooth signalStore transitions. Explore Nx workspace recipes for enterprise-scale patterns. Trust me, once you try it, you'll wonder why you waited so long!

Thanks for Reading 🙌

I hope these tips help you ship better, faster, and more maintainable frontend projects.

Author: Karol Modelski

Unlocking Productivity: AI Tools Every Angular Developer Should Know

Kafeel Ahmad — Wed, 07 Jan 2026 17:56:30 +0000

Imagine having an AI coding assistant right by your side — helping you avoid bugs, write cleaner code, and speed up your workflow.

This article explores how AI is changing the game for Angular developers. From smart code suggestions to tools that catch errors before they become problems, AI is making Angular development smoother and more productive.

Get ready to discover how these new tools and techniques can save time and make coding less stressful.

🤖 AI Coding Assistants Transforming Angular Development

Imagine having a coding partner who instantly suggests code, helps you fix bugs, and even writes documentation — all without taking a coffee break. AI assistants like GitHub Copilot, Claude, and ChatGPT are making this a reality for Angular developers, speeding up workflows and boosting productivity like never before.

Meet Your New Angular Sidekicks

AI coding assistants are no longer sci-fi — they are powerful tools integrated right inside your favorite IDEs. GitHub Copilot offers seamless autocomplete and chat features directly in VS Code, while Claude Code shines in handling multi-file projects and deep reasoning. ChatGPT jumps in with quick, detailed answers perfect for tricky Angular questions.

GitHub Copilot: Your go-to for real-time Angular and TypeScript snippets and test generation.
Claude Code: Masters big-picture tasks with IDE integration and project context awareness.
ChatGPT: Great for focused explanations and code fixes on demand.

Takeaway: Using these AI sidekicks together lets you code faster with more confidence and clarity.

How AI Makes Your Angular Day Easier

From spinning up components to writing tests and debugging, AI assistants handle the repetitive grunt work so you can focus on building great apps. They suggest code based on your current file and project context, debug with detailed explanations, and even generate helpful docs and tests.

Instant code suggestions save you from boilerplate headaches.
Debugging help breaks down issues step-by-step for quick fixes.
Automated tests and documentation boost code quality without extra effort.

Takeaway: Embedded AI tools keep you in the zone by cutting down context switching and repetitive tasks.

Real Examples, Real Gains

Let's see AI in action with Angular:

Need a new component? Ask AI to create a standalone counter with inputs, outputs, and slick OnPush change detection — minutes saved!
Updating to Angular 16's modern HttpClient? AI refactors your code and updates imports flawlessly.
Writing unit tests for form validations or mapping functions? AI drafts them complete with coverage for edge cases.
Crafting a typed UserService with RxJS operators and HttpParams? AI delivers production-ready code that fits right into your app.

Takeaway: Developers report up to 30% faster coding and testing, with cleaner code and fewer bugs thanks to AI helpers.

AI coding assistants have evolved from neat tools to essential teammates in Angular development. They're accelerating everything from scaffolding to debugging, all inside your IDE. With these tools in hand and Angular's AI best practices as a guide, building high-quality apps becomes faster and more enjoyable.

🔧 Angular Libraries and Developer Tools Leveraging AI

AI is shaking up the world of Angular development in exciting ways! From speeding up UI creation to catching bugs before they cause trouble, AI-powered tools are changing how developers work. This chapter dives into the coolest AI-driven libraries and tools making Angular development faster, smarter, and more fun.

Smart Angular Libraries That Think Ahead

Imagine a library that writes some of your UI code for you or suggests better ways to handle user input — sounds like magic, right? AI-enhanced Angular libraries do just that. They learn from patterns and automate tasks like creating components or validating forms with AI-powered insights. This means you spend less time on repetitive coding and more on building great features.

Key Takeaway 1: AI-powered libraries help you build UIs faster by automating common tasks.
Key Takeaway 2: They make apps smarter by adding features that adapt based on user behavior.

Testing and Debugging — Now with AI Superpowers!

Testing can be a headache, but AI is here to make it easier. AI-driven tools automatically create test cases by understanding your app's code and how users interact with it. They also spot bugs and performance issues early, often suggesting how to fix them. These smart helpers save hours, if not days, of manual testing and hunting for bugs.

Key Takeaway 1: AI tools cut down testing time by generating tests automatically.
Key Takeaway 2: Debugging gets faster with AI that pinpoints issues and suggests fixes.

Boosting Your Workflow with AI Integrations

What if your development tools could watch your app's performance and whisper ideas on how to make it better? AI integrations do just that by analyzing builds, runtime speed, and code quality right inside your workflow. They provide tips like lazy loading or smarter bundling to keep apps lightning-fast. Plus, AI-powered CI/CD pipelines catch build problems before they hit production, so you deploy with confidence.

Key Takeaway 1: AI keeps your Angular app running smoothly by spotting performance tips in real-time.
Key Takeaway 2: Continuous integration powered by AI means fewer surprises and faster releases.

AI is the new teammate every Angular developer wants. It takes care of the boring stuff and gives you supercharged insights so you can focus on what really matters — building amazing apps. Embracing AI tools means happier coding, fewer bugs, and better-performing Angular projects.

📋 Best Practices for Integrating AI Tools into Angular Workflows

AI is revolutionizing how we build apps, and Angular developers are right in the middle of this exciting change. But how can teams make the most of AI without losing control of code quality? This chapter is a quick guide to blending AI's power with Angular's best practices for smooth, safe, and smart workflows.

Managing AI-Generated Code Quality

AI can be a great coding partner, but it's not perfect. Think of AI-generated code as a draft that needs your expert polish. Always:

Double-check AI code with thorough reviews.
Use Angular-friendly linters and static analysis to catch issues.
Stick to strict typing—never settle for unclear any types.
Test everything with unit and integration tests.
Key Takeaway 1: AI code helps you start faster, but your review keeps it reliable.
Key Takeaway 2: Keep your tools sharp to maintain clean, consistent Angular code.

Combining AI with Signals in Angular

Angular Signals bring reactive magic to your app's state. When mixing AI and Signals:

Use Signals to keep state changes clear and reactive.
Let AI handle repetitive tasks but keep manual control on core state logic.
Avoid shortcuts that make your state unpredictable.
Key Takeaway 1: Signals keep your app's state neat and responsive.
Key Takeaway 2: AI is your helper, not your boss—stay in control of your state.

Avoiding Common Pitfalls

AI is tempting—fast suggestions, easy code—but beware! Don't let AI:

Push you to skip Angular best practices like OnPush change detection.
Flood your templates with complicated AI-generated logic.
Replace good architecture with quick fixes.
Key Takeaway 1: Understand every AI line before you include it.
Key Takeaway 2: Stick to solid design principles; AI is a tool, not a shortcut.

Practical AI + Angular Workflows

Here's a winning formula:

Kickstart your component or test with AI-generated code.
Review, refactor, and tune that code for your app's style.
Use AI-driven tools for catching bugs early.
Combine AI with Signals for slick, reactive apps.
Keep the human eye sharp with code reviews and CI checks.

Key Takeaway 1: AI speeds you up, but discipline keeps you on track.
Key Takeaway 2: Teamwork between AI and developers builds the best apps.

Embracing AI in Angular development unlocks new productivity levels—when done right. With solid reviews, Angular best practices, and a respectful partnership with AI, developers build great apps faster without losing quality.

🎯 Conclusion

AI is making life easier for Angular developers by helping them code faster and smarter.

Tools like GitHub Copilot give real-time suggestions, handle repetitive tasks, and catch mistakes early, saving valuable time. It's important to use AI as a helpful assistant — always double-check its suggestions and combine them with your own knowledge to keep your code clean and reliable.

While AI isn't perfect and sometimes makes errors, staying curious and connected with other developers can help you get the most out of these tools.

Try using AI in your Angular projects and explore resources like official documentation, workshops, and community forums to boost your skills and build great apps more quickly.

Thanks for Reading 🙌

I hope these tips help you ship better, faster, and more maintainable frontend projects.

Author: Karol Modelski

How we stopped shipping broken Angular code by making mistakes impossible

Kafeel Ahmad — Wed, 07 Jan 2026 17:33:03 +0000

Shipping bugs doesn't usually happen because developers are careless. It happens because teams rely on individual discipline instead of enforced systems.

Most teams are made up of developers with different backgrounds, learning paths, and mental models. That diversity is valuable — but without strict guardrails, it turns codebases into negotiation spaces. One developer tolerates any, another ignores lint warnings, someone else promises to "fix it later" and actually believes it. The product absorbs all of it.

Early in your career, this feels normal. You assume structure will emerge organically. It won't.

We've seen this story before with TypeScript itself. Many of us resisted it at first, complained about friction, and eventually realized it wasn't slowing us down — it was preventing entire classes of bugs. The same pattern repeats with every serious quality boundary we avoid enforcing.

I've started projects where junior developers defaulted to any, enabled ESLint only to silence it, skipped formatting rules, and treated lint errors as optional. Not because they were careless — but because the system quietly permitted it.

These are not people's problems. They are system failures.

When you design a product, you deliberately choose constraints. Code quality deserves the same level of intent. Rules should be explicit, enforced early, and impossible to bypass.

In this article, I'll walk through the tooling and discipline we use in Angular to make code predictable, scalable, and unemotional about quality — so mistakes are caught immediately, not negotiated in pull requests later.

Why Angular needs stricter enforcement than most frontend stacks

Angular is not fragile, but it is forgiving in dangerous ways.

On the surface, Angular feels structured: modules, decorators, dependency injection, lifecycle hooks. That apparent structure gives teams a false sense of safety. People assume the framework will "handle things" for them. It won't.

Angular applications hide complexity behind abstractions. A small mistake rarely fails loudly. It degrades quietly.

Templates are a second language. They look like HTML, but they behave like TypeScript — except the compiler won't save you unless you force it to. Without strict template checking, it's easy to ship runtime errors that no test or build step ever caught.

RxJS amplifies this problem. Subscriptions don't fail immediately when misused. They leak memory, duplicate side effects, and introduce timing bugs that only appear under load. Angular won't stop you from subscribing incorrectly. It will happily let the problem grow.

Dependency injection adds another layer of indirection. A service with loose typing or unsafe assumptions spreads risk across the entire application. One careless any doesn't stay local — it infects everything downstream.

None of this makes Angular bad. It makes it powerful. But power without enforcement is how technical debt becomes invisible.

In loosely structured stacks, mistakes are obvious early. In Angular, mistakes age quietly. By the time they hurt, they're baked into templates, services, and shared abstractions.

This is why Angular teams cannot rely on "best practices" as guidelines. They have to be rules. Enforced at build time. Enforced before code reaches review. Enforced before humans are asked to notice what tools could have caught instantly.

Tools don't create discipline — enforcement does

Most frontend teams already use the "right" tools.

TypeScript is enabled. ESLint exists. Prettier is installed. Tests run sometimes.

And yet the same problems persist.

That's because tools, by themselves, are passive. They suggest. They warn. They politely complain. Developers can ignore all of it and still ship code.

Discipline appears only when the system removes choice.

In our setup, tools are not helpers. They are gates. Each one exists at a specific stage of development, with a specific job: catch a class of mistakes as early as possible and stop the process immediately.

This isn't about trust. It's about economics. Fixing mistakes earlier is cheaper than discussing them later.

A note on configuration

This article focuses on why these constraints matter and how they work together as a system.

Full configuration files are intentionally not inlined here. They're verbose, change over time, and are better consumed directly. Complete setup references and links are provided at the end for anyone who wants to apply this approach in their own Angular project.

TypeScript strictness: the non-negotiable foundation

Before adding a single tool, strict typing has to be mandatory.

If strict mode is off, everything else is cosmetic. ESLint becomes advisory. Reviews turn subjective. Bugs escape silently.

Strict TypeScript forces the codebase to answer uncomfortable questions early:

What can actually be null?
What assumptions are unsafe?
Which APIs are lying about their contracts?

Turning strict mode on late feels painful because it exposes debt that was already there. That pain isn't a tooling issue — it's feedback.

In Angular, this also means enabling strict template type checking. Without it, a large portion of your application is effectively untyped. Runtime template errors become inevitable, and debugging them is far more expensive than preventing them.

Strictness doesn't slow teams down. It removes ambiguity — and ambiguity is where bugs hide.

ESLint: from style checker to design enforcer

Most teams stop too early with ESLint.

Used poorly, ESLint argues about formatting and naming. Used correctly, it enforces architecture.

In Angular, this means rules that:

Block any and unsafe type assertions
Prevent forgotten subscription teardowns
Catch floating promises and ignored async work
Enforce predictable RxJS patterns
Fail builds when unsafe assumptions leak into components or templates

If ESLint errors are allowed to pass "just this once", the system is already compromised.

ESLint is not there to nag developers. It exists so humans don't have to.

Prettier: eliminating meaningless choice

Formatting is not a quality signal. It's noise.

Prettier exists to eliminate that noise completely. No preferences. No debates. No pull-request comments about spacing.

It runs automatically, before code is committed. If formatting ever fails in CI, something upstream is broken.

This isn't about aesthetics. It's about preserving attention for problems that actually matter.

Husky and pre-commit hooks: enforcing standards at the only time that matters

Code review is too late to catch basic mistakes.

By the time a human sees the code, the system has already failed. At that point, the only options left are comments, rewrites, and follow-up commits — all avoidable work.

Pre-commit hooks move feedback to the moment code is written. When ESLint fails or formatting is wrong, the commit simply doesn't happen. There's no discussion, no negotiation, no "I'll fix it later". The system enforces the rule.

The key idea is graduated enforcement.

Not every check belongs at the same stage.

Fast, local feedback should happen continuously while writing code. Slightly heavier checks should block commits. The strictest checks should block pushes and fail CI. Each layer exists to catch mistakes at the cheapest possible point.

Continuous feedback while coding

Waiting until commit time is already late.

Linting should run while the developer is typing, not after they think they're done. This is where watch mode matters.

For example, running Angular and ESLint together:

{
  "scripts": {
    "dev": "ng lint && ng serve"
  }
}

This ensures the application doesn't even start if linting fails. The feedback is immediate.

For teams that want even tighter loops, ESLint can run independently in watch mode alongside the dev server:

{
  "scripts": {
    "dev": "concurrently \"ng serve\" \"eslint . --ext .ts,.html --watch\""
  }
}

This turns linting into a live signal instead of a delayed punishment. Errors appear while code is being written, not after context has already shifted.

This is especially effective when combined with Angular template linting and RxJS rules, where subtle mistakes are easy to miss and expensive to debug later.

Pre-commit: fast, unavoidable checks

Pre-commit hooks exist to stop bad code from entering history.

At this stage, only fast checks belong here:

ESLint on changed files
Prettier formatting

Nothing slow. Nothing flaky.

If a commit fails, the fix should take seconds, not minutes. Otherwise, developers will bypass the system — and a bypassable system is already broken.

This is where tools like Husky and lint-staged matter, not as setup details, but as enforcement mechanisms. The rule is simple: If the code doesn't meet the baseline, it doesn't get committed.

Pre-push and CI: stricter, slower, final

More expensive checks belong later.

Before pushing — and again in CI — the system can afford to be strict:

Full ng lint
Type checking with tsc --noEmit
Tests
Build validation

At this point, failure is intentional. It protects the shared branch, not the individual developer.

Importantly, CI should never be the first place an error is discovered. If CI catches issues developers never saw locally, feedback loops are too slow.

RxJS and Angular-specific enforcement

This setup becomes far more valuable when combined with Angular- and RxJS-specific lint rules.

Rules from eslint-plugin-rxjs and @angular-eslint/schematics catch issues humans routinely miss:

Forgotten subscription teardowns
Nested subscriptions
Unsafe async flows
Template misuse that compiles but fails at runtime

These are not stylistic preferences. They are bug prevention mechanisms.

Once enforced at commit time, these mistakes simply stop happening.

Commit discipline: code is not the only artifact

Quality doesn't stop at source files.

Commit history is part of the system. Vague messages like "fix", "final", or "working now" destroy context, slow debugging, and make releases harder than they need to be.

Structured commit messages turn history into documentation. They make intent explicit long after the code has changed.

This isn't bureaucracy. It's professional hygiene.

References and setup

Angular strict mode and strict templates
@angular-eslint and @typescript-eslint/strict
RxJS ESLint rules
Prettier
Husky, pre-commit and lint-staged
Commitlint and Conventional Commits

If you enjoyed reading this, a clap, follow, or comment would mean a lot. It literally takes a minute, but it's motivating for me to write more content like this.

Author: Ayush Maurya

Understanding afterNextRender(), afterEveryRender(), and afterRenderEffect() in Angular 18+

Kafeel Ahmad — Thu, 01 Jan 2026 05:47:25 +0000

Angular's reactivity model has evolved dramatically since the introduction of Signals. Alongside this fine-grained change detection came a new generation of render-aware hooks: afterNextRender(), afterEveryRender(), afterRenderEffect().

These hooks bridge the gap between reactivity and the actual DOM rendering phase, replacing many workarounds that previously relied on setTimeout() or heavy lifecycle juggling.

In this article, we'll explore how each hook works — not through dry theory, but via four hands-on exercises that reveal when and why to use them. By the end, we'll compare afterNextRender() with the old ngAfterViewInit() to see exactly why the new model is more predictable and fine-grained.

Task 1 — The First Render with afterNextRender()

Let's start simple:

import { Component, afterNextRender } from '@angular/core';

@Component({
  selector: 'app-timer',
  standalone: true,
  template: `<div #el>Timer works!</div>`,
})
export class TimerComponent {
  constructor() {
    afterNextRender(() => {
      console.log('DOM ready');
    });
  }
}

Question: When does console.log('DOM ready') fire? Answer: After the component's first DOM render — not immediately, and not during change detection.

afterNextRender() waits for the commit phase (the point when Angular finishes rendering to the DOM). It's perfect for DOM measurements, focus handling, or library initialization that must happen after the HTML is painted.

Task 2 — Continuous Updates with afterEveryRender()

Now let's see what happens when we re-render a component multiple times:

import { Component, signal, afterEveryRender } from '@angular/core';

@Component({
  selector: 'app-counter',
  standalone: true,
  template: `
    <div>{{ count() }}</div>
    <button (click)="increment()">+</button>
  `
})
export class CounterComponent {
  count = signal(0);

  constructor() {
    afterEveryRender(() => {
      console.log('Rendered with count =', this.count());
    });
  }

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

What happens:

Logs once after the first render,
Then again after every re-render triggered by a signal update.

afterEveryRender() doesn't react to all signals in the app — only when this component is actually re-rendered.

It's ideal for syncing DOM state or performing measurements when the view changes.

Task 3 — Reactive DOM Effects with afterRenderEffect()

This one brings everything together — reactivity and rendering:

code class="p-2 bg-gray-100 dark:bg-gray-900 overflow-x-auto language-typescript hljs" data-highlighted="yes">import { Component, signal, afterRenderEffect } from '@angular/core';

@Component({
  selector: 'app-progress',
  standalone: true,
  template: `<progress [value]="progress()" max="100"></progress>`,
})
export class ProgressComponent {
  progress = signal(0);

  constructor() {
    afterRenderEffect(() => {
      console.log('Render effect with progress', this.progress());
      if (this.progress() < 100) {
        this.progress.update(v => v + 25);
      }
    });
  }
}

Result: Logs five times — 0 → 25 → 50 → 75 → 100.

Each time, Angular commits the DOM and then re-runs the effect because the signal changed.

afterRenderEffect() automatically tracks signal dependencies and re-runs whenever they change and a new render occurs.

It's like a render-aware effect — the cleanest way to tie DOM updates to reactive data.

Task 4 — Comparing ngAfterViewInit() vs afterNextRender()

Let's look at a side-by-side example — a classic certification trap.

import { Component, ElementRef, ViewChild, afterNextRender } from '@angular/core';

@Component({
  selector: 'app-render-vs-viewinit',
  standalone: true,
  template: `
    <div #box class="demo-box">
      <h2>Demo</h2>
      <p>Content with font and padding.</p>
    </div>
  `,
  styles: [`
    .demo-box {
      padding: 24px;
      border: 1px solid #ccc;
      /* simulate delayed style application */
      animation: applyHeight 0s 1 forwards;
    }
    @keyframes applyHeight {
      to { margin-top: 20px; }
    }
  `]
})
export class RenderVsViewInitComponent {
  @ViewChild('box', { static: true }) box!: ElementRef<HTMLDivElement>;

  constructor() {
    afterNextRender(() => {
      const h = this.box.nativeElement.getBoundingClientRect().height;
      console.log('[afterNextRender] height =', h);
    });
  }

  ngAfterViewInit() {
    const h = this.box.nativeElement.getBoundingClientRect().height;
    console.log('[ngAfterViewInit] height =', h);
  }
}

Result:

The first log (ngAfterViewInit) appears earlier — during the same change detection cycle.
The second (afterNextRender) runs later, after Angular has committed the DOM and processed layout.
The height measured in afterNextRender() is often larger or more accurate (reflecting applied CSS/layout changes).

Summary — Old vs. New Hooks

ngAfterViewInit()

Fires: after the view is created, before DOM commit
Best for: getting references (ViewChild)
Works in SSR: Yes

afterNextRender()

Fires: after the DOM is fully rendered and styles applied
Best for: DOM measurements, focus, third-party libs
Works in SSR: No

afterEveryRender()

Fires: after every re-render of the component
Best for: logging, syncing, UI instrumentation
Works in SSR: No

afterRenderEffect()

Fires: after each render caused by signal changes
Best for: reactive side effects tied to DOM
Works in SSR: No

Takeaways

afterNextRender() is asynchronous relative to change detection — it "waits" until the DOM is ready.
afterEveryRender() tracks actual renders, not all reactive updates.
afterRenderEffect() automatically re-runs based on signal dependencies.
These hooks do not run during SSR, which helps prevent hydration errors.
Don't mutate state in afterEveryRender() — it can lead to render loops. Use afterRenderEffect() instead.

Conclusion

Techniques once considered standard — like ngAfterViewInit() and setTimeout() — may now be seen as legacy workarounds. The modern Angular render scheduler and its trio of hooks bring true fine-grained reactivity: predictable, DOM-aware, and cleanly separated from change detection.

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don't receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don't forget to clap and follow the writer️!

Author: Maciej Osytek

How Angular Signal Forms Handle Validation CSS Classes

Kafeel Ahmad — Wed, 31 Dec 2025 19:23:22 +0000

Understanding CSS Classes in Angular Signal Forms

If you've started experimenting with Angular's new Signal Forms API, you might have experienced a small panic moment :

"Wait… where are ng-invalid, ng-touched, and the other familiar CSS classes?"

You're not alone.

For years, Angular developers have relied on these built-in status classes to:

Style validation errors
Trigger UI feedback
Integrate with design systems

So when they suddenly disappear, it feels like a step backward.

But it's not.

In fact, Signal Forms give us something better: explicit, fully controlled CSS class binding.

Let's break it down

Why Signal Forms Don't Auto-Apply `ng-*` Classes

Signal Forms were designed with predictability and explicitness in mind.

Instead of Angular automatically mutating the DOM with implicit CSS classes, Signal Forms require you to decide:

Which classes exist
When they are applied
What logic controls them

This avoids:

Hidden side effects
Implicit DOM mutations
Tight coupling to legacy CSS conventions

But don't worry — Angular didn't abandon us.

Reintroducing Status Classes (On Your Terms)

Angular provides a way to define your own CSS status classes using a global configuration.

You do this via a provider that tells Angular:

"Apply this class when this condition is true."

The Shape of the Configuration

At a high level, the configuration looks like this:

Copy{

  classes: {

    [className: string]: (state: Field<unknown>, element?: HTMLElement) => boolean;

  }

}

Keys → CSS class names
Values → Predicate functions
Return value → true means "apply this class"

Example 1: Restoring Classic Validation Classes

Let's start with the familiar ones — renamed for clarity and originality.

Copyimport { provideSignalFormsConfig, DEFAULT_STATUS_CLASSES } from '@angular/forms';

export const appFormProviders = [

  provideSignalFormsConfig({

    classes: {

      ...DEFAULT_STATUS_CLASSES

    }

  })

];

This immediately brings back behavior similar to:

invalid
touched
dirty
pristine

Without Angular forcing them onto every field.

Example 2: Custom Error Styling Logic

Now let's do something we couldn't easily do before.

Apply a CSS class only when:

The field is invalid
And the user has interacted with it

CopyprovideSignalFormsConfig({

  classes: {

    'field-error-visible': (controlState) =>

      controlState().invalid() && controlState().interacted()

  }

});

Result

Your UI stays clean until the user actually engages with the form — no more premature red borders 👌

Example 3: Conditional Classes Based on Element Type

You can even apply classes based on the actual DOM element.

CopyprovideSignalFormsConfig({

  classes: {

    'multi-line-input': (, domNode) =>

      domNode?.tagName.<span class="hljs-title function">toLowerCase() === 'textarea'

  }

});

This is incredibly powerful for:

Design systems
Component libraries
Advanced form layouts

Comparison: Old Forms vs Signal Forms

Here's a quick breakdown 👇

Why This Is Actually a Big Upgrade

At first glance, losing automatic CSS classes feels uncomfortable.

But Signal Forms give us:

Explicit UI logic
Better separation of concerns
More predictable DOM behavior
Powerful conditional styling
Cleaner design system integration

Instead of Angular deciding for you, you're fully in control now.

Final Thoughts

Signal Forms don't remove functionality — they promote intentional design.

Once you start defining your own class logic:

You'll write clearer styling rules
Debugging becomes easier
Your forms scale better across large apps

The initial surprise fades quickly — and what's left is a cleaner, more expressive form system.

This article builds upon patterns shared by Roberto Hecker in his exploration of Signal forms

Author: Angular_with_Awais

The Developer's Guide to Stunning UI: How to Build Without a Designer

Kafeel Ahmad — Wed, 31 Dec 2025 19:20:32 +0000

Hi there 👋

Have a great app idea, but uncertain about design and UX? Not a designer yourself, and don't have one on your team? This article is for you!

Many developers have brilliant ideas and can build apps with their preferred tech stack and code quality standards. But let's be honest — we're not always great at design, and product teams need both developers and designers.

Here's the good news: You can autonomously build outstanding UIs that rival professional UX/UI designs. The solution? Leverage AI trained on millions of interfaces, giving it collective experience that's hard to beat.

Tools I Used for This Workflow

Here's my stack for this design-to-code journey:

— No-code platforms: Lovable, Blink, Bolt (for brainstorming initial UI generation)

— Antigravity: Google's agentic platform (like Cursor, for example)

— Gemini 1.5 Pro & Claude: LLMS

— My vibe coding setup: Angular 21 + Tailwind v4 + DaisyUI v5

Ready? Let's dive in.

The Real Use Case

I'll use a real project I vibe-coded for my niece to show you how this works. (This article focuses on design, not the vibe coding whole app process itself.)

Alright, so how are we going to use AI? Vibe coding right away? Nope. Actually, vibe coding comes next, after you have your app's mockup and system design ready.

The secret? Use no-code platforms. And fortunately, there are a LOT of them, which gives us tons of different designs and options to choose from.

Here are my favorites:

Lovable
Blink
Bolt

I've vibe-coded a lot of Angular apps, and I can say that out of these platforms, Lovable was often outstanding. There are plenty of other choices you can add to the list, but these are my go-to platforms.

Now, knowing what AI tools can help us with app design is not enough. We also need to know how to use them to get the best results!

Step 1: Be Smart at Dealing with Your AI App Builder

Build a Strong Prompt for the MVP Version of Your App

Why?

Overly complex prompts overwhelm the agent's context window, leading to incomplete implementations, hallucinations, or ignored features as the model struggles to prioritize.

We don't want that. We want our coding agent to be in good health so it can perform at its best. And speaking of good health 😂, we also need to ask it to do what it excels at — meaning let it choose the stack to use. Don't specify any stack yourself. Using a technology stack unfamiliar to a coding agent increases the chance of generating flawed, non-functional code. Although our goal here is design, not code quality, getting stuck solving error problems with follow-up prompts will waste time, effort, and cause unnecessary struggle.

How?

You can list all your MVP features with short descriptions to an LLM (ChatGPT, Gemini, or Claude) and ask it to polish and clarify them, since this will be used as a prompt for a no-code platform to build your app.

My Real Use Case Prompt

For my project, here's the prompt I used:

CopyKids' Language Pronunciation Learning App

Features Implemented
1. Image-to-Text Flow
Home Page: Users can upload an image (mocked) or use sample text.
OCR Service: Mocked service simulates text extraction.
Text Editor: Users can edit the extracted text before starting.

2. Learning Modes
Listen Mode: TTS reads the text aloud. Words are highlighted as they are spoken (simulated). Speed controls available.
Practice Mode: Users can record their voice (mocked). STT simulates recognition.

3. Interactive Words
Word Modal: Clicking a word opens a modal with definition and syllable breakdown (mocked).
Pronunciation: Users can listen to individual words.
Save to Difficult Words: Users can save words to a list.

4. Progress & Dashboard
Difficult Words Page: Displays saved words. Users can listen to or remove words.

Navigation: Easy navigation between Home, Learning, and Difficult Words pages.
Use mock data at the bigining

💡 Key Powers of This Approach

Mock-First Approach: Notice the duplicated usage of "mock" and "simulate" words. Mandating "mock data at the beginning" enables rapid iteration — my app ships with simulated OCR/TTS/STT/recording, yielding a working UI/flow instantly. You get extractable design assets right away, bypassing real API hurdles.
Modularity: The bullet-point format mirrors agent strengths, creating navigable pages (Home, Learning, Difficult Words) and interactions (word modals, speed controls) as discrete, testable units.
Anti-Bloat Guardrails: Keeping things ultra-concise with "no expansions" eliminates feature creep, focusing only on high-value paths like text editing → highlighting → recording → saving.

The use of "mock data" is really a key here. It tells the agent: "Don't worry about getting feature logic working at the beginning — just focus on the UI."

Step 2: Compare, Improve, Adjust, and Take Screenshots

Now, at this stage, you have 3 choices (or more, depending on how many no-code platforms you used). You can compare them — how do you feel about each one? You can even publish these and share them with test users who can give you quick feedback on their user experience.

When you've found the one you like (for me, it's Lovable), you can fine-tune it if needed with a few prompts or add more features. Remember: we don't want to bombard the agent at the beginning. Now that we have a solid base, we can add features one by one (always in mock mode).

When you're done, take screenshots, save them in a mockup folder, and download the app's CSS style file.

💡 Reverse-Engineering the Design

We'll use the CSS style file to reverse-engineer the design from it.

By the way, you could use it as-is if it matches the UI library you'll use. However, for my case, it doesn't reflect my requirements. Even if I use only Tailwind CSS without DaisyUI, the current no-code platforms are trained heavily on Tailwind CSS v3. But I want to use the latest version, v4, which has a completely different setup compared to v3:

ℹ️ Tailwind CSS v4 shifts to a CSS-first configuration with faster Oxide engine builds, unlike v3's JavaScript config and PostCSS approach.

What I Added in My Use Case:

i18n support with a new settings tab
The possibility of taking a picture in the upload image feature
In the learning phase, I added a seek bar below the speed slider so users can go backward or forward when listening to the speaker
Real-time feedback: Instead of displaying "what I heard," I want the mispoken word highlighted with a wavy underline so users know which words need to be pronounced properly

Results:

Links to other designs:

Bolt
Blink

Step 4: Generate Your App's Design System Requirements Prompt

With the style file and mockups, you have the perfect ingredients to generate a design system for your app. This design system can be used as a relevant context when vibe coding.

Again, we can rely on AI (I used Gemini Pro 3) to generate a solid prompt that will create this design system requirement and take into consideration the UI library you want to use.

The Workflow

<a rel="noopener follow" href="https://github.com/famzila/word-wonder/blob/main/.agent/workflows/design-system-specs-generator.md">


            <h2>word-wonder/.agent/workflows/design-system-specs-generator.md at main · famzila/word-wonder</h2>

                <h3>An interactive, AI-powered language pronunciation learning tool designed specifically for children aged 6-10. It…</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">github.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/0*_otijISa8GEApMtT'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

💡 Assuming you want to use Angular Material: You'll need to adapt the design system constraints. Use something like "The design system must conform to Material Design (M3) principles and terminology." But the most important thing here is CONTEXT. To avoid surprises or outdated code, you need context — meaning a material-llms.txt file where you gather how the latest Material version (or the version you want to use) works, its best practices, dos and don'ts. This is super important.

Feeding It to the AI

The result was fed to Gemini 3 Pro in Antigravity (it has a 1 million token context window).

The Output

And…the output is a very strong design system requirements doc that translates visual intent into concrete, reusable, and enforceable primitives that developers can actually build against.

Key Powers as a Developer Resource

— Strong Tokenization

Colors, radius, shadows, gradients, and motion are all defined as reusable tokens
Enables scalability, theming, and framework/UI library-agnostic implementation

— Clear Semantic Intent

Tokens and utilities are tied to usage, not just appearance
Reduces ambiguity and prevents inconsistent UI decisions

— Behavior Included (Not Just Styles)

Animations and shadows are documented as interaction primitives
Motion has meaning, improving UX consistency and accessibility readiness

Utility-First Friendly

Maps cleanly to Tailwind/atomic CSS workflows
Developers can implement without a design tool dependency

Implicit Constraints

Strong visual rules (rounding, colored shadows) guide consistency
Though explicit "do/don't" constraints could strengthen it further

Overall: This document functions as a solid design-system specification extracted from code. It's implementation-ready, scalable, and minimizes developer guesswork — well above average for CSS-derived requirements.

⚠️ Important note: My prompt was guided toward a result that can help my coding agent implement the app's design properly based on specific stacks like Tailwind CSS, DaisyUI, etc. You can adjust it to fit your needs.

Here's the design system requirements doc:

<a rel="noopener follow" href="https://github.com/famzila/word-wonder/blob/main/public/specs/DESIGN_SYSTEM.md">


            <h2>word-wonder/public/specs/DESIGN_SYSTEM.md at main · famzila/word-wonder</h2>

                <h3>An interactive, AI-powered language pronunciation learning tool designed specifically for children aged 6-10. It…</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">github.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/0*EzOSqnt47jF0cyJW'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

Step 5: How You Can Use This Design System Requirements File

Now that we have the design system requirements document, we can move to implementation planning. I created another prompt specifically for this task (adjust it based on the stack you want to use).

<a rel="noopener follow" href="https://github.com/famzila/word-wonder/blob/main/.agent/workflows/frontend-system-architect.md">


            <h2>word-wonder/.agent/workflows/frontend-system-architect.md at main · famzila/word-wonder</h2>

                <h3>An interactive, AI-powered language pronunciation learning tool designed specifically for children aged 6-10. It…</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">github.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/0*aCdKHMADe2GC4plp'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

As you can see in this prompt, I need the following inputs:

The system design requirements doc
The mockups (screenshots)
The UI library's llms.txt (for my case, DaisyUI — from the official DaisyUI docs, which also covers Tailwind CSS specifications, so no need to add them separately)

⚠️ Antigravity supports 5 images. This might seem like a limitation, but actually, providing more mockups will only result in poor results. Remember: asking for too much always causes the LLM to not perform at its best.

The Output

<a rel="noopener follow" href="https://github.com/famzila/word-wonder/blob/main/public/specs/FRONTEND_PLANNING.md">


            <h2>word-wonder/public/specs/FRONTEND_PLANNING.md at main · famzila/word-wonder</h2>

                <h3>An interactive, AI-powered language pronunciation learning tool designed specifically for children aged 6-10. It…</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">github.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/0*rOUbngEMSuPjxd7q'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

— Perfect Translation Layer:

Maps every design token (color.coral) directly to implementation
Zero ambiguity — coding agent knows exactly which daisyUI class to use

— Component Blueprint:

Each component has clear inputs/outputs/responsibilities.
Smart vs Dumb separation prevents spaghetti code
Styling strategy defined per component type (buttons use btn btn-primary shadow-button rounded-box)

— Implementation-Ready:

Exact CSS variable names for Tailwind v4 + daisyUI v5
Animation keyframe names specified
Responsive patterns defined

— Risk Mitigation:

Rules section prevents common mistakes ("Never use bg-[#...]")
Accessibility requirements explicit
Framework migration gotchas documented

— Efficiency Boost:

No back-and-forth asking "what should this look like?"
No redesigning components mid-development
Vibe coding agent has complete context to generate correct code first try

This doc transforms mockups into buildable specifications. It's the Rosetta Stone between design and code — your vibe coding agent can reference this and generate components that match your design system perfectly without hallucinating styles or guessing structure. And of course, you can always adapt it after review, human in the loop is important. For example, some of the dumb components are not necessary from my point of view.

💡 Pro Tip: Convert Prompts to Reusable Workflows

Convert all the prompts we've used so far into Antigravity workflows, Claude SKILLs, or slash commands to avoid repeating yourself. With this, you'll only need to call the prompt with "/" instead of copy-pasting it every time you need it.

Step 6: Execute the Frontend Plan

Now that you have the Frontend Plan, don't just let it sit there. It is your roadmap for the actual coding phase. Here is how to use it effectively:

Generate Global Styles & Tokens: Use the plan to generate your global CSS variables and theme immediately. Get the colors, typography, and spacing utilities defined before writing a single line of feature logic.
Scaffold "Dumb" Components First: Before building complex features, ask the coding agent to "prepare the ground". Have it implement your shared, presentational components.

ℹ️ Why? This solves a common AI problem where agents duplicate code (eg. tab menu, stepper, …) for every new feature. By pre-building these "dumb" components, you force the agent to reuse them, keeping your codebase clean and consistent.

Use it as a Context Guide: Whenever you start a new feature (e.g., "Build the Learn"), paste the relevant section of the Frontend Plan into the chat context. This ensures the agent adheres to the architectural decisions you've already made, rather than guessing.

⚠️ It's important to note that when implementing features in Angular, always feed your agent the mockup along with the frontend planning doc. Generative AI is non-deterministic, so don't freak out if the first output isn't perfect. You'll probably need 2–3 follow-up prompts to fine-tune it and get the UI to match your mockup. That's normal — iteration is the name of the game!

Ah, and by the way, you can also let your coding agent suggest design alternatives and test them out. If you don't like it, just revert. That was my case with the favorite words modal. I actually liked Gemini 3 Pro's suggestion better than my original lovable mockup!

Final Touch — Audit & Review

Even with a perfect plan, AI is not perfect. Models often have a "knowledge cutoff" or strong training bias toward older versions of libraries, leading them to generate outdated or deprecated code (e.g., using custon css class when the latest docs suggest a different utility).

💡 Pro Tip: The "Second Opinion" Strategy
Always perform your audit using a different LLM than the one that generated the code.

Why? If the first model (e.g., Claude 3.5 Sonnet) made a mistake, it is biased to defend it. A fresh model (e.g., Gemini 1.5 Pro or other) will spot the error immediately.
Be Specific: Don't just dump the whole documentation. Provide the llms.txt file and targeted links to the specific components involved.
Example: If the agent built a Card component, include the direct URL to the DaisyUI Card API documentation in your prompt. This forces the auditor to cross-reference the code against the exact official source.

Here is my implemented UI with Antigravity, Gemini 3 PRO, and Claude:

It's almost identical to the Lovable UI, isn't it? 😎

Here is a demo

I have already shared my experiment to build this app in this article. Check it out here if you are interested ;)

<a rel="noopener follow" href="https://levelup.gitconnected.com/when-antigravity-meets-production-ready-modern-angular-app-42b0c7d94388">


            <h2>When Antigravity Meets Production-Ready Modern Angular App</h2>

                <h3>Embracing Antigravity workflows and the Playground</h3>

            <div class="mt-5">
                <p class="text-xs text-grey-darker">gitconnected.com</p>
            </div>
        </div>
        <div class="relative flex h-40 flew-row w-60">
            <div class="absolute inset-0 bg-center bg-cover" style="background-image: url('https://miro.medium.com/v2/resize:fit:320/1*QnjWtCkcn210uTMM2oHS3A.png'); background-repeat: no-repeat;" referrerpolicy="no-referrer"></div>
        </div>
    </div>
</a>

Conclusion

And there you have it! A complete workflow to design stunning apps without being a designer yourself. The key takeaways:

Use AI-powered no-code platforms to generate multiple design options quickly
Start with MVP and mock data to keep your agent focused
Compare and iterate
Extract and reverse-engineer the design into a proper system requirements doc
Use that doc as context for your actual implementation

Now go build something beautiful! 🚀

That's it for today 👋
If you enjoyed this article, consider liking or subscribing so you don't miss the next one 😉

Let's stay connected! You can find me on LinkedIn, Instagram, YouTube, or X.
And hey, if you feel like sending a virtual coffee my way ☕️ 😊

Thank you ❤️

Author: FAM

DEV Community: Kafeel Ahmad

Building a Simple REST API with Express.js — The Right Way

🧱 Project Structure

🧪 Step-by-Step: Create a Simple API

1. Install Express

2. Create server.js

3. Create app.js

4. Add a Controller (controllers/userController.js)

5. Add a Route (routes/userRoutes.js)

🛡️ Add Environment Config

🔒 Add Error Handling Middleware

📦 Bonus: Add CORS & Helmet for Security

✅ Final Output

🔚 Final Thoughts

Node.js in 2026: Modern Practices You Should Be Using

1. ES Modules(ESM) First

Why It Matters:

Best Practices:

2. Native fetch API Support

Why It Matters:

Best Practices:

3. Modern Testing with Vitest

Why It Matters:

4. Bun Compatibility

Why It Matters:

Best Practices:

5. TypeScript, Even for Small Projects

Why It Matters:

Best Practices:

6. Dotenv is (Still) Your Friend — But Don't Hardcode

Best Practices:

7. Zero-Config Dev Environments

8. Process Management with PM2: Keep Your Node App Alive

Why It Matters:

Best Practices:

Final Thoughts:

Node.js Architecture Patterns for Scalable Apps (2026 Guide)

Why Architecture Matters in Node.js

1. Layered (Monolithic) Architecture

2. Microservices Architecture

3. Event-Driven Architecture

4. Serverless Architecture

5. Clean / Hexagonal Architecture

Scaling Node.js Beyond Architecture

Final Thoughts

Domain-Driven Design (DDD) with Node.js: Best Practices for Large Projects

What is Domain-Driven Design (DDD)?

Why Use DDD in Node.js?

Core Building Blocks of DDD

Node.js Project Structure with DDD

Example: User Registration in DDD

1. Entity: User

2. Value Object: Email

3. Repository Interface

4. Application Service (Use Case): RegisterUser

5. Infrastructure: MongoDB Repository Implementation

6. Connecting Everything

Best Practices for DDD in Node.js

Final Thoughts

Building a Simple REST API with Express.js — The Right Way

🧱 Project Structure

🧪 Step-by-Step: Create a Simple API

1. Install Express

2. Create server.js

3. Create app.js

4. Add a Controller (controllers/userController.js)

5. Add a Route (routes/userRoutes.js)

🛡️ Add Environment Config

🔒 Add Error Handling Middleware

📦 Bonus: Add CORS & Helmet for Security

✅ Final Output

🔚 Final Thoughts

Connect with Me

A message from our Founder

How to Become a Pro in Node.js ( Roadmap for Serious Devs)

📍 Step 1: Master the Core Before You Touch Frameworks

📦 Step 2: Know the Module System Inside-Out

🧵 Step 3: Understand the Event Loop & Asynchronous Nature

⚙️ Step 4: Deep Dive into Express & Middleware

🧱 Step 5: Build Real APIs (REST + GraphQL)

2. Create `server.js`

3. Create `app.js`

4. Add a Controller (`controllers/userController.js`)

5. Add a Route (`routes/userRoutes.js`)

2. Native `fetch` API Support

2. Create `server.js`

3. Create `app.js`

4. Add a Controller (`controllers/userController.js`)

5. Add a Route (`routes/userRoutes.js`)