DEV Community: Neweraofcoding

How to Build a Modern Chrome Extension with Manifest V3 Best Practices

Neweraofcoding — Sat, 12 Sep 2026 11:20:25 +0000

Browser extensions are one of the fastest ways to build high-impact tools using the frontend skills you already have (HTML, CSS, and JavaScript).

However, if your experience was based on Manifest V2, building extensions in 2026 requires adapting to Manifest V3 (MV3) standards—including event-driven service workers, stricter Content Security Policies (CSP), and promise-based Chrome APIs.

What’s Covered in This Guide:

Structuring manifest.json under Manifest V3 specifications
Designing popup UIs and styling with modern CSS
Working with event-driven background service workers
Injecting and managing content scripts safely
Cross-component messaging via chrome.runtime.sendMessage
Managing persistent state using chrome.storage.local

Check out the full tutorial and code snippets on SunnyWriteUps.

Get Started with Kotlin: Building Your First Android App with Jetpack Compose

Neweraofcoding — Tue, 08 Sep 2026 04:05:23 +0000

If you've been wanting to build native Android apps, there's never been a better time to jump in. The days of juggling XML layouts, findViewById, and fragmented lifecycle logic are behind us.

Modern Android development is entirely Kotlin-first, powered by Jetpack Compose—Google's modern declarative UI toolkit.

In this tutorial, we cover:

Setting up your development environment in Android Studio
Understanding declarative UI with @Composable functions
Managing UI state and handling user events
Leveraging interactive previews to speed up design iterations
Running and debugging your app on emulators and real devices

Read the full tutorial on SunnyWriteUps.

How to Build and Publish Your First Python Package to PyPI

Neweraofcoding — Thu, 03 Sep 2026 05:24:03 +0000

Publishing your own library to the Python Package Index (PyPI) turns a local script into a globally installable tool with a single command: pip install your-package.

If you've been putting off package creation because older tooling felt convoluted, modern Python standards (pyproject.toml) make the process clean and predictable.

What We Cover:

Setting up the recommended src/ directory structure
Configuring pyproject.toml with metadata, licenses, and build backends
Building source distributions and wheels using python -m build
Testing your upload safely against TestPyPI
Publishing to production PyPI with API token security

Read the complete walkthrough on SunnyWriteUps.

How to Create and Publish Your First Rust Package (Crate)

Neweraofcoding — Tue, 01 Sep 2026 18:08:41 +0000

Building and distributing reusable code is a major milestone in Rust. In the Rust ecosystem, packages are called crates, and they are managed through Cargo—Rust’s official build system and package manager.

In this guide, we cover:

Scaffolding binary vs. library crates
Setting up metadata and dependencies in Cargo.toml
Best practices for testing and generating documentation
Publishing your package to crates.io

Check out the full walkthrough on SunnyWriteUps.

Angular Lite: Architecting a Compiler with Gemini

Neweraofcoding — Mon, 17 Aug 2026 14:18:30 +0000

Can AI help architect a frontend compiler? 🤔 I just published a deep dive into a Gemini-powered Angular "Lite" prototype.

We are moving past AI generating basic components and into AI-assisted system architecture.

Read the full breakdown here 👇
https://sunnyblog.apexmansunny.workers.dev/posts/angular-compiler-with-gemini/

Angular #GeminiAI #WebDev

The Core of Angular Configuration

Neweraofcoding — Wed, 05 Aug 2026 19:00:01 +0000

You write the code, but what manages the workspace? Uncover the secrets of angular.json, the unsung hero and central command center of every Angular application. Join me for a tour of the control room.

https://sunnyblog.apexmansunny.workers.dev/posts/angular/the-control-room-of-your-angular-workspace/

Browser APIs That Can Replace Third-Party Libraries

Neweraofcoding — Mon, 27 Jul 2026 16:09:41 +0000

Modern browsers are far more powerful than most developers realize. Beyond rendering web pages, they provide a rich ecosystem of native APIs that enable applications to access device capabilities, work offline, interact with hardware, communicate in real time, and deliver experiences that rival native apps—all without relying on heavy third-party libraries.

In this article, I explore the world of Native Browser APIs, explaining how modern web applications can leverage built-in browser features such as the File System Access API, Clipboard API, Web Share API, Geolocation, Notifications, Web Bluetooth, WebUSB, WebRTC, and many more. Along the way, you'll discover practical use cases, real-world examples, browser compatibility considerations, and best practices for building secure, performant, and future-ready web applications.

Whether you're a frontend developer, full-stack engineer, or simply curious about the evolving capabilities of the web platform, this guide will help you unlock the true potential of modern browsers and build experiences that are faster, smarter, and more engaging—using the APIs already available in the browser. Inspired by the continued evolution of the web platform and modern browser capabilities, this article serves as a practical guide to leveraging native features that reduce dependencies while improving user experience.

https://sunnyblog.apexmansunny.workers.dev/posts/unlocking-the-power-of-the-web-a-guide-to-native-browser-apis/

The Agentic Stack: Discover the Gemini Enterprise Agent Platform.

Neweraofcoding — Fri, 26 Jun 2026 17:33:28 +0000

Learn how to move from building single agents to managing a mission control of thousands of them – all with complete governance.

The Agentic Stack: Why Managing Thousands of AI Agents Is the Next Enterprise Revolution

For the past two years, the AI industry has been obsessed with one question:

"How do we build better AI agents?"

But we're now entering a new era where that question is no longer enough.

The real challenge isn't creating one intelligent agent—it's managing thousands of them.

Imagine an enterprise where every department has its own specialized AI:

A customer support agent answering tickets.
A finance agent processing invoices.
An HR agent screening resumes.
A legal agent reviewing contracts.
A DevOps agent monitoring infrastructure.
A sales agent qualifying leads.
A marketing agent creating campaigns.

Now imagine these agents working together, sharing context, using enterprise data, and operating under strict governance.

That's what the Agentic Stack is all about.

It's not just another AI framework—it's a blueprint for building an enterprise powered by intelligent, autonomous systems.

The Shift: From Single Agents to Agent Ecosystems

Most developers begin by building a single AI assistant.

It can answer questions, summarize documents, or automate a workflow.

That's a great starting point.

But enterprises don't operate through a single workflow.

They run hundreds of interconnected processes every day.

Instead of one AI assistant, organizations need an ecosystem of specialized agents that collaborate to achieve business goals.

Think of it like a modern company:

Employees specialize in different functions.
Teams collaborate across departments.
Managers coordinate priorities.
Governance ensures compliance and accountability.

The future of AI follows the same model.

What Is the Agentic Stack?

The Agentic Stack is the foundation for building, deploying, orchestrating, and governing AI agents at enterprise scale.

Rather than treating AI as a chatbot, it treats agents as digital workers with clearly defined responsibilities.

A complete Agentic Stack typically includes:

1. Specialized AI Agents

Each agent has a focused responsibility instead of trying to solve every problem.

Examples include:

Customer Support Agent
Sales Assistant
Research Agent
Document Intelligence Agent
Data Analyst Agent
Infrastructure Monitoring Agent

Specialization improves both reliability and performance.

2. Agent Orchestration

Real business problems often require multiple steps.

A customer asking for a refund might trigger:

Customer Agent

↓

Order Verification Agent

↓

Fraud Detection Agent

↓

Finance Agent

↓

Notification Agent

No single agent should handle the entire process.

Instead, orchestration ensures the right agent performs the right task at the right time.

3. Shared Enterprise Knowledge

An AI agent without business context is like a new employee on their first day.

To make informed decisions, agents need secure access to:

Internal documentation
Knowledge bases
CRM systems
ERP platforms
Product catalogs
Company policies
Historical conversations

Retrieval-Augmented Generation (RAG) helps agents retrieve relevant information instead of relying only on model memory.

4. Tool Integration

Enterprise agents create value when they take action.

Instead of only generating text, they should be able to:

Create Jira tickets
Send emails
Query databases
Schedule meetings
Generate reports
Trigger APIs
Update CRMs
Monitor cloud infrastructure

An agent becomes truly useful when it can move from reasoning to execution.

5. Memory and Context

Modern AI agents shouldn't forget every conversation after a single interaction.

Persistent memory enables them to:

Remember previous customer interactions
Track ongoing projects
Personalize recommendations
Maintain long-running workflows

Context transforms isolated conversations into continuous collaboration.

Why Governance Matters More Than Intelligence

As organizations deploy hundreds—or even thousands—of AI agents, governance becomes the foundation of trust.

Without governance, businesses risk:

Data leaks
Unauthorized actions
Compliance violations
Hallucinated responses
Inconsistent decision-making

Enterprise AI requires guardrails, including:

Identity and Access Control

Every agent should have clearly defined permissions.

A marketing agent should never access payroll records.

A finance agent shouldn't modify engineering systems.

Audit Logs

Every decision should be traceable.

Organizations need visibility into:

Which agent acted
What information it used
Which tools it accessed
Why a decision was made

Transparency is essential for compliance and debugging.

Human Approval

Not every action should be fully autonomous.

Critical tasks—such as financial transactions, legal approvals, or customer escalations—should include human review.

The goal isn't to replace people.

It's to automate routine work while preserving human oversight where it matters most.

The Mission Control for AI Agents

Imagine opening a dashboard that shows:

2,500 active AI agents
Real-time health monitoring
Task completion rates
Agent collaboration graphs
Cost per workflow
Success and failure metrics
Security alerts
Compliance status

This becomes the mission control center for enterprise AI.

Just as Kubernetes transformed how we manage containers, the next generation of platforms will transform how we manage AI agents.

The future isn't about launching one agent.

It's about operating an entire workforce of them.

Challenges Enterprises Must Solve

Scaling AI agents isn't just a technical problem.

Organizations need to address:

Cost Optimization

Thousands of AI agents can generate significant inference costs.

Smart orchestration determines:

Which model to use
When to cache responses
When smaller models are sufficient
When reasoning models are necessary

Efficiency becomes a competitive advantage.

Security

AI agents interact with sensitive systems.

Protecting customer data requires:

Encryption
Role-based access control
Secret management
Secure API authentication
Data isolation

Security must be built into the architecture—not added later.

Observability

Traditional monitoring tracks servers and APIs.

Agentic systems also need to measure:

Task success rates
Decision quality
Tool usage
Latency
Hallucination frequency
Human intervention rates

Without observability, improving AI systems becomes guesswork.

Why This Changes Enterprise Software

Enterprise software has evolved through distinct phases:

Manual workflows
Digitized applications
Cloud-native platforms
AI copilots
Agentic enterprises

The next generation of software won't simply help employees work faster.

It will delegate meaningful work to autonomous, governed AI agents that collaborate across business functions.

This isn't about replacing humans.

It's about enabling people to focus on creativity, strategy, and innovation while AI handles repetitive, structured work at scale.

Final Thoughts

The conversation around AI is rapidly shifting.

Building a single AI chatbot is no longer enough.

The organizations that gain the greatest advantage will be those that can orchestrate thousands of specialized agents, connect them to enterprise knowledge, govern their behavior, and continuously monitor their performance.

The future belongs not to the company with the smartest individual agent—but to the one with the most effective Agentic Stack.

The next enterprise operating system won't just run applications.

It will coordinate an intelligent workforce of AI agents working together toward a common goal.

The age of autonomous enterprises has begun.

Scaling Real-Time Applications

Neweraofcoding — Wed, 24 Jun 2026 03:00:55 +0000

The Tech Behind Uber & WhatsApp A discussion on real-time messaging, WebSockets, Firebase, and high-performance APIs.

Today's most successful products—ride-sharing platforms, messaging apps, live collaboration tools, gaming platforms, and financial systems—all share one thing in common: they're real-time.

When you book a cab, send a WhatsApp message, or collaborate on a Google Doc, you're not refreshing the page every few seconds. Data flows instantly between users and servers with minimal latency.

But building these applications isn't as simple as opening a WebSocket connection.

As someone who has designed distributed systems and real-time platforms, I've learned that the real challenge isn't making something work for 100 users—it's making it work reliably for 10 million concurrent users.

Let's dive into the architecture behind modern real-time applications.

Scaling Real-Time Applications: The Tech Behind Uber & WhatsApp

Real-Time Isn't Magic—It's Engineering

Imagine ordering an Uber.

Within seconds:

Your location updates continuously
Nearby drivers receive your request
One driver accepts it
The driver's location updates every few seconds
ETA changes in real time
Notifications arrive instantly
Payment status syncs immediately

All of this happens across thousands of servers while millions of users perform the same actions simultaneously.

The same applies to WhatsApp.

Every message needs to:

Reach the recipient instantly
Be delivered exactly once
Work on unstable mobile networks
Synchronize across multiple devices
Preserve message order
Scale globally

Achieving this requires a carefully designed architecture rather than a single technology.

Understanding Real-Time Communication

Traditional web applications operate on a request-response model.

Client → Request
Server → Response

The browser asks.

The server answers.

Conversation ends.

This works well for websites but not for live systems.

Imagine refreshing WhatsApp every second to check for new messages.

That would be incredibly inefficient.

Instead, modern applications maintain an always-open communication channel between client and server.

This is where WebSockets come into play.

Why WebSockets Changed Everything

HTTP connections are short-lived.

Client -----> Server
       Request

Server -----> Client
       Response

A WebSocket connection stays open.

Client <=====================> Server
         Persistent Connection

Now both sides can communicate whenever necessary.

The server no longer waits for the client to ask.

It pushes updates instantly.

Benefits include:

Lower latency
Reduced bandwidth usage
Instant notifications
Live dashboards
Multiplayer gaming
Chat applications
Real-time collaboration

The Lifecycle of a Chat Message

Suppose Alice sends:

"Hey, are you free?"

Here's what actually happens behind the scenes.

Alice

↓
WebSocket

↓
API Gateway

↓
Authentication

↓
Message Queue

↓
Message Service

↓
Database

↓
Notification Service

↓
Recipient WebSocket

↓
Bob

Each step serves a specific purpose.

Authentication verifies the sender.

Queues absorb traffic spikes.

Databases store message history.

Notification services wake offline devices.

This modular architecture keeps the platform resilient under heavy load.

Why Polling Doesn't Scale

Some beginners implement chat applications using polling.

Every second

Client
   ↓
"Any new messages?"

Server
   ↓
"No."

Repeat forever.

Multiply this by one million users.

Now your servers process millions of unnecessary requests every second.

Most of them return nothing.

That's wasted CPU, bandwidth, and infrastructure cost.

WebSockets eliminate this problem by sending data only when something changes.

Building a High-Performance API

Real-time applications still depend heavily on APIs.

Good API design focuses on:

Fast responses

Keep endpoints lightweight.

Avoid unnecessary database joins.

Cache wherever possible.

Stateless servers

Never store user session data inside server memory.

Instead, use:

JWT tokens
Redis
Distributed session stores

Stateless services scale horizontally with ease.

Compression

Enable:

Gzip
Brotli
Binary protocols

Every byte matters when millions of users communicate simultaneously.

Pagination

Never return:

GET /messages

Return:

GET /messages?page=1&limit=20

Small payloads improve performance dramatically.

Firebase: Real-Time Without Managing Servers

Not every startup needs to build Uber's infrastructure from scratch.

That's where Firebase shines.

Firebase provides:

Authentication
Real-time database
Firestore
Push notifications
Cloud Functions
Storage
Analytics

A client simply listens for updates.

db.collection("messages")
.onSnapshot(snapshot => {
    console.log(snapshot.docs);
});

Whenever the database changes, connected clients receive updates automatically.

No WebSocket management required.

But Firebase Isn't Always the Answer

Firebase works wonderfully for:

MVPs
Hackathons
Startup prototypes
Internal tools

However, very large applications often outgrow it.

Common reasons include:

Vendor lock-in
Expensive reads at scale
Complex querying limitations
Multi-region architecture challenges
Custom infrastructure requirements

Large organizations usually combine multiple technologies instead.

Scaling Beyond One Server

Imagine your chat server receives:

100,000 WebSocket connections

One server won't survive.

Instead:

Load Balancer

      │
 ┌────┼────┐
 │    │    │
Server A
Server B
Server C

Connections spread across multiple servers.

This is called horizontal scaling.

But now another challenge appears.

What if Alice connects to Server A while Bob connects to Server C?

How does Server C know Alice sent a message?

The answer is a distributed messaging system.

Enter Message Brokers

Systems like:

Kafka
RabbitMQ
Redis Pub/Sub
NATS

act as communication layers between services.

Alice

↓

Server A

↓

Kafka

↓

Server C

↓

Bob

No matter which server users connect to, every message reaches its destination.

Caching: Your Secret Performance Weapon

Databases are slow compared to memory.

Instead of querying the database repeatedly:

Database

store frequently accessed data in:

Redis

Examples include:

User profiles
Online status
Session tokens
Recent chats
Driver locations

Caching reduces latency from hundreds of milliseconds to just a few milliseconds.

Handling Millions of Concurrent Connections

Keeping millions of WebSockets open requires careful optimization.

Best practices include:

Event-driven servers
Non-blocking I/O
Connection pooling
Heartbeat monitoring
Idle connection cleanup
Efficient serialization
Rate limiting

Languages commonly used include:

Go
Node.js
Java
Rust
Erlang

Each offers different strengths for high-concurrency workloads.

Reliability Matters More Than Speed

Real-time systems must also handle failures gracefully.

Questions every engineer should ask:

What happens if a server crashes?
How are messages retried?
Can duplicate messages occur?
What if a user reconnects?
How are offline users synchronized?
What happens during network partitions?

Building a system that recovers automatically is often more valuable than making it slightly faster.

Monitoring Is Non-Negotiable

You can't improve what you can't measure.

Track metrics such as:

Active WebSocket connections
API latency
Error rates
Queue depth
Message delivery time
CPU and memory usage
Network throughput

Tools like Prometheus, Grafana, OpenTelemetry, and distributed tracing help identify bottlenecks before users notice them.

Common Mistakes Engineers Make

I've seen these issues repeatedly in production systems:

❌ Using polling instead of WebSockets for real-time features.

❌ Storing sessions in server memory, making horizontal scaling difficult.

❌ Querying the database for every incoming message instead of caching.

❌ Ignoring backpressure, causing queues to grow uncontrollably during traffic spikes.

❌ Sending oversized JSON payloads when compact formats or selective updates would suffice.

❌ Skipping monitoring until production issues arise.

These mistakes may not appear during development but become painfully obvious as traffic grows.

A Reference Architecture

A scalable real-time platform often looks like this:

               Clients
                  │
          CDN / Load Balancer
                  │
          API Gateway / Auth
                  │
      ┌───────────┴───────────┐
      │                       │
 REST APIs             WebSocket Gateway
      │                       │
      └───────────┬───────────┘
                  │
           Message Broker
        (Kafka / RabbitMQ)
                  │
     ┌────────────┼────────────┐
     │            │            │
 Chat Service  Notification  Presence
     │            │            │
     └────────────┼────────────┘
                  │
        Redis Cache + Database
                  │
     Monitoring & Observability

This architecture separates responsibilities, making the system easier to scale, maintain, and evolve independently.

Final Thoughts

Building a real-time application isn't about choosing WebSockets over HTTP or Firebase over a custom backend. It's about designing a system that remains fast, reliable, and resilient as your user base grows.

Companies like Uber and WhatsApp didn't achieve scale through a single technology. They invested in solid architectural principles: stateless services, message brokers, caching, observability, fault tolerance, and horizontal scalability.

Whether you're building a chat application, a live dashboard, a collaborative editor, or a ride-sharing platform, the same lesson applies:

Real-time systems aren't built by making servers faster—they're built by designing architectures that distribute work efficiently, recover gracefully from failures, and continue performing under massive scale.

The next time you see a message appear instantly or watch a driver's location move across a map in real time, remember that behind that seamless experience lies a carefully orchestrated ecosystem of WebSockets, distributed services, caches, queues, and APIs—all working together to make "instant" feel effortless.

Beyond CRUD: Architecting Event-Driven Systems

Neweraofcoding — Mon, 22 Jun 2026 07:42:45 +0000

For years, CRUD (Create, Read, Update, Delete) has been the foundation of backend application development. Most business applications revolve around storing, retrieving, updating, and deleting data in relational databases. While CRUD works exceptionally well for many use cases, modern distributed applications demand something more.

Today's systems power millions of users, process real-time events, integrate with dozens of services, and require resilience even when components fail. This is where Event-Driven Architecture (EDA) changes the game.

In this session, we'll explore how technologies like Apache Kafka, Google Cloud Pub/Sub, and Event Sourcing help backend engineers build scalable, loosely coupled, and fault-tolerant systems that go far beyond traditional CRUD operations.

Why CRUD Isn't Enough

Imagine an e-commerce platform.

When a customer places an order, several things happen:

Inventory should decrease.
Payment should be processed.
Shipping should be scheduled.
Notification emails should be sent.
Analytics should capture the purchase.
Loyalty points should be updated.

In a CRUD-based monolith, a single service often performs all these actions sequentially. As the application grows, this leads to:

Tight coupling between services
Complex deployments
Difficult scaling
Cascading failures
Slow feature development

Every new feature means modifying existing business logic.

There is a better way.

Thinking in Events Instead of Database Operations

An event represents something that has already happened.

Examples include:

OrderPlaced
PaymentCompleted
UserRegistered
ProductUpdated
ShipmentDelivered

Instead of directly calling every downstream service, an application simply publishes an event.

Other services subscribe to the events they care about.

This creates a system where producers and consumers are completely independent.

Customer Places Order

        │
        ▼

 Order Service
        │
 Publishes Event
        │
        ▼

+----------------------+
|   Event Broker       |
+----------------------+
   │      │      │
   ▼      ▼      ▼

Inventory   Payment   Notification
 Service     Service      Service

This simple architectural shift dramatically improves scalability and maintainability.

Apache Kafka: The Distributed Event Backbone

Apache Kafka is one of the most widely adopted platforms for event streaming.

Instead of treating data as rows in a database, Kafka treats everything as an immutable stream of events.

Key Concepts

Topics

Logical channels where events are stored.

Example:

orders
payments
shipments
users

Producers

Applications that publish events.

Order Service
        │
        ▼
Kafka Topic: orders

Consumers

Applications that listen to events.

Inventory Service
Payment Service
Email Service
Analytics Service

Each service independently processes the same event.

Why Kafka Works So Well

Kafka provides:

High throughput
Horizontal scalability
Fault tolerance
Event replay
Persistent storage
Consumer independence

Unlike traditional message queues, Kafka retains events for configurable periods, allowing systems to replay historical events whenever needed.

Google Cloud Pub/Sub

While Kafka often requires infrastructure management, Google Cloud Pub/Sub provides a fully managed messaging service.

It offers:

Automatic scaling
Serverless architecture
Global availability
Push and pull subscriptions
Integration with cloud-native services

For organizations already on Google Cloud Platform, Pub/Sub significantly reduces operational overhead while providing reliable event delivery.

Event Sourcing: Storing Events Instead of State

Traditional databases only store the current state.

Example:

Account Balance = $850

But how did it become $850?

That history is lost.

Event Sourcing takes a completely different approach.

Instead of storing the latest value, it stores every change.

Account Created
+$1000 Deposit
-$200 Withdrawal
+$50 Cashback

Current Balance = $850

The application's state is reconstructed by replaying all events.

Benefits of Event Sourcing

Complete Audit Trail

Every business action is permanently recorded.

Perfect for:

Banking
Healthcare
Financial systems
Compliance-heavy applications

Time Travel

Need to know what the system looked like yesterday?

Replay events until yesterday.

Need to investigate a bug?

Replay historical events.

Easy Debugging

Instead of asking:

"What happened?"

You already know.

Every change exists as an event.

Multiple Read Models

The same event stream can power different projections:

Customer dashboards
Reporting databases
Search indexes
Analytics platforms

Each optimized for different workloads.

The CQRS Pattern

Event-driven systems often pair Event Sourcing with Command Query Responsibility Segregation (CQRS).

CQRS separates:

Commands

Create Order
Update User
Cancel Booking

from Queries

Get Order History
Search Products
View Dashboard

Commands write events.

Queries read optimized views built from those events.

This separation allows each side to scale independently.

Real-World Example

Consider an online food delivery platform.

When an order is placed:

OrderPlaced

This single event triggers:

Inventory Service

Reserve ingredients

Payment Service

Charge customer

Delivery Service

Assign rider

Notification Service

Send SMS

Analytics Service

Update dashboard

Recommendation Engine

Learn customer preferences

No service directly calls another.

Each reacts independently.

Adding a new service later doesn't require modifying existing code—simply subscribe to the relevant events.

Challenges of Event-Driven Systems

Like any architectural style, event-driven systems introduce their own complexities.

Eventual Consistency

Data isn't instantly synchronized across services.

Developers must design systems that tolerate temporary inconsistencies.

Duplicate Events

Consumers may receive the same event multiple times.

Services should be idempotent so processing an event twice doesn't produce incorrect results.

Ordering

In distributed systems, events may arrive out of sequence.

Proper partitioning and ordering strategies are critical.

Observability

Tracking a request across multiple services becomes more difficult.

Distributed tracing tools such as OpenTelemetry, Jaeger, and Zipkin become essential.

Best Practices

When designing event-driven systems:

Design immutable events.
Version event schemas carefully.
Keep events business-focused.
Build idempotent consumers.
Avoid excessive event chaining.
Monitor consumer lag.
Use dead-letter queues for failures.
Document event contracts clearly.

When Should You Use Event-Driven Architecture?

EDA shines when building:

Microservices
Real-time analytics
IoT platforms
Financial systems
E-commerce platforms
Logistics applications
Streaming platforms
High-scale SaaS products

For simple CRUD applications, a relational database may still be the best choice. Event-driven architecture is most valuable when systems require scalability, resilience, and asynchronous communication.

Final Thoughts

CRUD isn't obsolete—it remains a fundamental building block for countless applications. However, as systems grow in complexity and scale, relying solely on synchronous database operations can become a bottleneck.

Event-driven architecture introduces a new mindset: instead of asking "How do I update the database?", ask "What business event just occurred?"

Technologies like Apache Kafka, Google Cloud Pub/Sub, and Event Sourcing empower backend engineers to build systems that are more scalable, resilient, and adaptable to change.

The future of backend engineering isn't just about managing data—it's about designing systems that react to events, evolve independently, and thrive in distributed environments.

Because modern software isn't just CRUD anymore—it's a continuous stream of meaningful events.

Hacking the Cloud: What Every Engineer Should Know About Cloud Security

Neweraofcoding — Thu, 04 Jun 2026 14:29:08 +0000

Cloud computing has transformed how organizations build, deploy, and scale applications. From startups launching their first products to global enterprises managing millions of users, cloud platforms provide unprecedented flexibility and speed.

However, with great convenience comes great responsibility.

Contrary to popular belief, moving workloads to the cloud does not automatically make them secure. In fact, many of the largest cloud security incidents in recent years were caused not by sophisticated hackers exploiting zero-day vulnerabilities, but by simple misconfigurations, excessive permissions, and overlooked security controls.

As organizations continue their cloud journey, every engineer—not just security professionals—must understand the fundamentals of cloud security.

The Shared Responsibility Model

One of the biggest misconceptions about cloud security is assuming that the cloud provider handles everything.

Major providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) operate under a shared responsibility model.

The cloud provider is responsible for:

Physical data center security
Hardware and networking infrastructure
Managed service availability
Hypervisor and platform security

Customers are responsible for:

Identity and access management
Application security
Data protection
Network configurations
Operating system security (for self-managed workloads)

A cloud provider secures the cloud, but customers must secure what they put in the cloud.

Real-World Cloud Vulnerabilities

Let's examine some of the most common cloud security issues that attackers exploit.

1. Misconfigured Storage Buckets

One of the most frequent causes of cloud data breaches is publicly accessible storage.

Engineers often create storage buckets for testing or temporary file sharing and accidentally leave them exposed to the internet.

Common mistakes include:

Public read permissions
Public write permissions
Missing encryption policies
Lack of access logging

Attackers continuously scan cloud environments searching for exposed storage containing:

Customer records
Source code
API keys
Internal documents
Database backups

A single misconfigured bucket can expose millions of sensitive records.

2. Overly Permissive IAM Roles

Identity and Access Management (IAM) is the backbone of cloud security.

Unfortunately, many organizations grant broad permissions simply because it is faster than implementing least-privilege access.

Examples include:

Using administrator privileges for applications
Sharing service accounts across environments
Granting wildcard permissions (*)
Long-lived credentials without rotation

If attackers compromise a single account with excessive permissions, they may gain access to an entire cloud environment.

The principle of least privilege should always be the default approach.

3. Exposed Secrets and Credentials

Cloud environments rely heavily on secrets such as:

API keys
Database passwords
SSH keys
OAuth tokens
Service account credentials

A common mistake is storing these secrets in:

Git repositories
Container images
Configuration files
CI/CD pipelines

Attackers frequently scan public repositories for exposed credentials. Once discovered, they can use those credentials to move laterally across cloud systems.

Engineers should leverage dedicated secret management services and implement automatic credential rotation whenever possible.

4. Insecure Containers and Kubernetes Deployments

Containers have become the standard deployment model for modern applications, but they introduce unique security challenges.

Common vulnerabilities include:

Running containers as root
Using outdated base images
Exposing management interfaces
Weak Kubernetes RBAC policies
Unrestricted pod communication

A vulnerable container can become an entry point into a larger cloud environment.

Security scanning should be integrated into every container build process.

5. Unpatched Cloud Workloads

While cloud providers maintain infrastructure security, customers remain responsible for patching operating systems and applications running on virtual machines.

Attackers actively exploit:

Unpatched Linux servers
Outdated web frameworks
Legacy software components
Known CVEs

Automated patch management and vulnerability scanning are essential components of cloud security.

The Rise of Cloud-Native Attacks

Modern attackers no longer focus solely on traditional network attacks.

Today's threat actors target cloud-native resources such as:

Kubernetes clusters
Serverless functions
Cloud APIs
CI/CD pipelines
Infrastructure-as-Code repositories

For example, an attacker who gains access to a poorly secured CI/CD pipeline may inject malicious code into production systems without ever touching a server.

This shift requires engineers to think beyond firewalls and embrace security throughout the software delivery lifecycle.

Security Misconfigurations Engineers Should Watch For

During cloud security assessments, the following issues appear repeatedly:

Networking

Open security groups
Publicly accessible databases
Unrestricted inbound traffic
Flat network architectures

Identity

Shared accounts
Excessive privileges
Lack of multi-factor authentication
Dormant accounts

Data Protection

Unencrypted storage
Missing backup policies
Weak key management
Lack of data classification

Monitoring

Disabled audit logs
Insufficient alerting
Missing threat detection
Incomplete visibility across cloud accounts

Most cloud breaches occur because these basic controls were overlooked.

Building a Secure Cloud Environment

Security should be integrated from the beginning rather than added later.

Adopt Infrastructure as Code

Tools like Terraform and CloudFormation allow organizations to define infrastructure consistently and securely.

Benefits include:

Repeatable deployments
Version-controlled infrastructure
Automated security checks
Reduced configuration drift

Implement Zero Trust Principles

Never assume trust based on network location.

Instead:

Verify every identity
Authenticate every request
Continuously validate access
Restrict permissions aggressively

Enable Continuous Monitoring

Cloud environments change constantly.

Security teams should continuously monitor:

Access patterns
Configuration changes
Privilege escalations
Suspicious API activity

The faster anomalies are detected, the faster they can be contained.

Secure the CI/CD Pipeline

Your deployment pipeline is one of the most valuable targets for attackers.

Protect it through:

Strong authentication
Signed artifacts
Secret scanning
Dependency scanning
Role separation

A secure application cannot be built from an insecure pipeline.

The Future of Cloud Security

Cloud adoption continues to accelerate, and attackers are evolving just as quickly.

Emerging trends include:

AI-driven threat detection
Automated security remediation
Cloud Security Posture Management (CSPM)
Container runtime protection
Supply chain security validation

Organizations that treat security as a continuous engineering practice rather than a compliance exercise will be better positioned to defend against future threats.

Final Thoughts

Cloud platforms provide incredible opportunities for innovation, but they also expand the attack surface in ways many organizations underestimate.

The majority of cloud breaches do not occur because hackers are exceptionally clever. They happen because basic security principles were ignored: excessive permissions, exposed credentials, misconfigured storage, and inadequate monitoring.

Every engineer who deploys cloud workloads influences an organization's security posture. Understanding common vulnerabilities, adopting secure-by-design practices, and continuously validating configurations are no longer optional skills—they are essential responsibilities.

In the cloud, security is not a feature. It is an engineering discipline.

Getting Started with Unit Testing in a Node.js Project with Jest

Neweraofcoding — Sun, 03 May 2026 12:55:51 +0000

When building backend applications with Node.js, most developers focus heavily on APIs, databases, and business logic—but often skip testing until bugs start showing up.

Unit testing helps you catch bugs early, improve code quality, and refactor with confidence.

In this blog, we’ll learn how to set up unit testing in a Node.js + TypeScript project using Jest.

What is Unit Testing?

Unit testing means testing small isolated pieces of code (functions, services, controllers) to verify they work as expected.

Example:

Instead of testing the full API flow:

Client → Route → Controller → Database

We test only:

Function → Input → Expected Output

This makes debugging faster and easier.

Why Use Jest?

Jest is one of the most popular testing frameworks because it provides:

✅ Zero-config setup
✅ Fast execution
✅ Mocking support
✅ Built-in assertions
✅ TypeScript support
✅ Code coverage reports

Step 1: Create a Node.js Project

Initialize a project:

npm init -y

Install TypeScript:

npm install typescript ts-node @types/node -D

Initialize TypeScript config:

npx tsc --init

Step 2: Install Jest

Install Jest and TypeScript support:

npm install jest ts-jest @types/jest -D

Initialize Jest config:

npx ts-jest config:init

This creates:

jest.config.js

Step 3: Configure TypeScript

Update tsconfig.json

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "esModuleInterop": true,
    "strict": true
  }
}

Important settings:

target → JavaScript version output
module → module system
esModuleInterop → better import compatibility

Step 4: Create Sample Code

Project structure:

src/
 ├── controllers/
 │   └── itemController.ts
 ├── models/
 │   └── item.ts
tests/
 └── itemController.test.ts

Create model:

// src/models/item.ts

export const items: string[] = [];

Create controller:

// src/controllers/itemController.ts

import { Request, Response } from 'express';
import { items } from '../models/item';

export const getItems = (
  req: Request,
  res: Response
) => {
  res.json(items);
};

Step 5: Write Your First Test

Create:

// tests/itemController.test.ts

import { Request, Response } from 'express';
import { getItems } from '../src/controllers/itemController';
import { items } from '../src/models/item';

describe('Item Controller', () => {
  it('should return empty array', () => {
    const req = {} as Request;

    const res = {
      json: jest.fn()
    } as unknown as Response;

    items.length = 0;

    getItems(req, res);

    expect(res.json).toHaveBeenCalledWith([]);
  });
});

Understanding the Test

describe()

Groups related tests.

describe('Item Controller', () => {})

it()

Defines a single test case.

it('should return empty array', () => {})

jest.fn()

Creates a mock function.

json: jest.fn()

Useful for checking:

was it called?
how many times?
what arguments?

expect()

Assertion API.

expect(res.json).toHaveBeenCalledWith([]);

Verifies output.

Step 6: Add Test Script

Update package.json

{
  "scripts": {
    "test": "jest"
  }
}

Run tests:

npm test

Output:

PASS tests/itemController.test.ts

Common Jest Matchers

Check equality

expect(value).toBe(10);

Check object equality

expect(obj).toEqual({});

Check if function was called

expect(mockFn).toHaveBeenCalled();

Check call count

expect(mockFn).toHaveBeenCalledTimes(1);

Mocking Dependencies

Suppose your controller calls a service:

import { getData } from './service';

Mock it:

jest.mock('./service');

Set return value:

(getData as jest.Mock).mockReturnValue([]);

This isolates your unit.

Running Coverage

Generate coverage report:

npm test -- --coverage

Output:

Statements   : 95%
Branches     : 90%
Functions    : 100%
Lines        : 96%

Aim for good coverage, not just high numbers.

Best Practices

Keep tests isolated

Each test should run independently.

Mock external dependencies

Avoid hitting real databases or APIs.

Use descriptive test names

Good:

should return empty items array

Bad:

test 1

Follow AAA Pattern

Arrange → Act → Assert

Example:

// Arrange
const req = {};

// Act
getItems(req, res);

// Assert
expect(res.json).toHaveBeenCalled();

Final Thoughts

Unit testing is not optional in production-grade applications.

With Jest, getting started is simple:

Install Jest
Configure TypeScript
Write tests
Mock dependencies
Run coverage

Start small.

Test one controller.

Then one service.

Then one utility.

Over time, your project becomes safer, cleaner, and easier to maintain.

Your future self will thank you.