How we combined three open AI protocols — Google's A2A & ADK with Anthropic's MCP — to build a production-ready Multi-Agent Research Assistant using .NET 10.

Introduction

The AI space is constantly changing and improving. Once again, we've moved past the single LLM calls and into the future of Multi-Agent Systems, in which expert AI agents act in unison as a collaborative team.

But here is the problem: How do you make agents communicate with each other? How do you equip agents with tools? How do you control them?

Three open protocols have emerged for answering these questions:

• MCP (Model Context Protocol) by Anthropic — The "USB-C for AI"
• A2A (Agent-to-Agent Protocol) by Google — The "phone line between agents"
• ADK (Agent Development Kit) by Google — The "organizational chart for agents"

In this article, I will briefly describe each protocol, highlight the benefits of the combination, and walk you through our own project: a Multi-Agent Research Assistant developed via ABP Framework.

The Problem: Why Single-Agent Isn't Enough

Imagine you ask an AI: "Research the latest AI agent frameworks and give me a comprehensive analysis report."

A single LLM call would:

• Hallucinate search results (can't actually browse the web)
• Produce a shallow analysis (no structured research pipeline)
• Lose context between steps (no state management)
• Can't save results anywhere (no tool access)

What you actually need is a team of specialists:

1. A Researcher who searches the web and gathers raw data
2. An Analyst who processes that data into a structured report
3. Tools that let agents interact with the real world (web, database, filesystem)
4. An Orchestrator that coordinates everything

This is exactly what we built.

Protocol #1: MCP — Giving Agents Superpowers

What is MCP?

MCP (Model Context Protocol): Anthropic's standardized protocol allows AI models to be connected to all external tools and data sources. MCP can be thought of as the USB-C of AI – one port compatible with everything.

Earlier, before MCP, if you wanted your LLM to do things such as search the web, query a database, and store files, you would need to write your own integration code for each capability. MCP lets you define your tools one time, and any agent that is MCP-compatible can make use of them.

How MCP Works

MCP follows a simple Client-Server architecture:

The flow is straightforward:

1. Discovery: The agent asks "What tools do you have?" (tools/list)
2. Invocation: The agent calls a specific tool (tools/call)
3. Result: The tool returns data back to the agent

MCP in Our Project

We built three MCP tool servers:

| MCP Tool | Purpose | Used By | |----------|---------|---------| | web_search | Searches the web via Tavily API | Researcher Agent | | fetch_url_content | Fetches content from a URL | Researcher Agent | | save_research_to_file | Saves reports to the filesystem | Analysis Agent | | save_research_to_database | Persists results in SQL Server | Analysis Agent | | search_past_research | Queries historical research | Analysis Agent |

The beauty of MCP is that you do not need to know how these tools are implemented inside the tool. You simply need to call them by their names as given in the description.

Protocol #2: A2A — Making Agents Talk to Each Other

What is A2A?

A2A (Agent to Agent), formerly proposed by Google and now presented under the Linux Foundation, describes a protocol allowing one AI agent to discover another and trade tasks. MCP fits as helping agents acquire tools; A2A helps them acquire the ability to speak.

Think of it this way:

• MCP = "What can this agent do?" (capabilities)
• A2A = "How do agents talk?" (communication)

The Agent Card: Your Agent's Business Card

Every A2A-compatible agent publishes an Agent Card — a JSON document that describes who it is and what it can do. It's like a business card for AI agents:

{
  "name": "Researcher Agent",
  "description": "Searches the web to collect comprehensive research data",
  "url": "https://localhost:44331/a2a/researcher",
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "web-research",
      "name": "Web Research",
      "description": "Searches the web on a given topic and collects raw data",
      "tags": ["research", "web-search", "data-collection"]
    }
  ]
}

Other agents can discover this card at /.well-known/agent.json and immediately know:

• What this agent does
• Where to reach it
• What skills it has

How A2A Task Exchange Works

Once an agent discovers another agent, it can send tasks:

The key concepts:

• Task: A unit of work sent between agents (like an email with instructions)
• Artifact: The output produced by an agent (like an attachment in the reply)
• Task State: Submitted → Working → Completed/Failed

A2A in Our Project

Agent communication in our system uses A2A:

• The Orchestrator finds all agents through the Agent Cards
• It sends a research task to the Researcher Agent
• The Researcher’s output (artifacts) is used as input by Analysis Agent - The Analysis Agent creates the final structured report

Protocol #3: ADK — Organizing Your Agent Team

What is ADK?

ADK (Agent Development Kit), created by Google, provides patterns for organizing and orchestrating multiple agents. It answers the question: "How do you build a team of agents that work together efficiently?"

ADK gives you:

• BaseAgent: A foundation every agent inherits from
• SequentialAgent: Runs agents one after another (pipeline)
• ParallelAgent: Runs agents simultaneously
• AgentContext: Shared state that flows through the pipeline
• AgentEvent: Control flow signals (escalate, transfer, state updates)

Note: ADK's official SDK is Python-only. We ported the core patterns to .NET for our project.

The Pipeline Pattern

The most powerful ADK pattern is the Sequential Pipeline. Think of it as an assembly line in a factory:

Each agent:

1. Receives the shared AgentContext (with state from previous agents)
2. Does its work
3. Updates the state
4. Passes it to the next agent

AgentContext: The Shared Memory

AgentContext is like a shared whiteboard that all agents can read from and write to:

This pattern eliminates the need for complex inter-agent messaging — agents simply read and write to a shared context.

ADK Orchestration Patterns

ADK supports multiple orchestration patterns:

| Pattern | Description | Use Case | |---------|-------------|----------| | Sequential | A → B → C | Research → Analysis pipeline | | Parallel | A, B, C simultaneously | Multiple searches at once | | Fan-Out/Fan-In | Split → Process → Merge | Distributed research | | Conditional Routing | If/else agent selection | Route by query type |

How the Three Protocols Work Together

Here's the key insight: MCP, A2A, and ADK are not competitors — they're complementary layers of a complete agent system.

Each protocol handles a different concern:

| Layer | Protocol | Question It Answers | |-------|----------|-------------------| | Top | ADK | "How are agents organized?" | | Middle | A2A | "How do agents communicate?" | | Bottom | MCP | "What tools can agents use?" |

Our Project: Multi-Agent Research Assistant

Built With

• .NET 10.0 — Latest runtime
• ABP Framework 10.0.2 — Enterprise .NET application framework
• Semantic Kernel 1.70.0 — Microsoft's AI orchestration SDK
• Azure OpenAI (GPT) — LLM backbone
• Tavily Search API — Real-time web search
• SQL Server — Research persistence
• MCP SDK (ModelContextProtocol 0.8.0-preview.1)
• A2A SDK (A2A 0.3.3-preview)

How It Works (Step by Step)

Step 1: User Submits a Query

For example, the user specifies a field of research in the dashboard: “Compare the latest AI agent frameworks: LangChain, Semantic Kernel, and AutoGen”, and then specifies execution mode as ADK-Sequential or A2A.

Step 2: Orchestrator Activates

The ResearchOrchestrator receives the query and constructs the AgentContext. In ADK mode, it constructs a SequentialAgent with two sub-agents; in A2A mode, it uses the A2AServer to send the tasks.

Step 3: Researcher Agent Goes to Work

The Researcher Agent:

• Receives the query from the context
• Uses GPT to formulate optimal search queries
• Calls the web_search MCP tool (powered by Tavily API)
• Collects and synthesizes raw research data
• Stores results in the shared AgentContext

Step 4: Analysis Agent Takes Over

The Analysis Agent:

• Reads the Researcher's raw data from AgentContext
• Uses GPT to perform deep analysis
• Generates a structured Markdown report with sections:
  • Executive Summary
  • Key Findings
  • Detailed Analysis
  • Comparative Assessment
  • Conclusion and Recommendations
• Calls MCP tools to save the report to both filesystem and database

Step 5: Results Returned

The orchestrator collects all results and returns them to the user via the REST API. The dashboard displays the research report, analysis report, agent event timeline, and raw data.

Two Execution Modes

Our system supports two execution modes, demonstrating both ADK and A2A approaches:

Mode 1: ADK Sequential Pipeline

Agents are organized as a SequentialAgent. State flows automatically through the pipeline via AgentContext. This is an in-process approach — fast and simple.

Mode 2: A2A Protocol-Based

Agents communicate via the A2A protocol. The Orchestrator sends AgentTask objects to each agent through the A2AServer. Each agent has its own AgentCard for discovery.

The Dashboard

The UI provides a complete research experience:

• Hero Section with system description and protocol badges
• Architecture Cards showing all four components (Researcher, Analyst, MCP Tools, Orchestrator)
• Research Form with query input and mode selection
• Live Pipeline Status tracking each stage of execution
• Tabbed Results view: Research Report, Analysis Report, Raw Data, Agent Events
• Research History table with past queries and their results

Why ABP Framework?

We chose ABP Framework as our .NET application foundation. Here's why it was a natural fit:

| ABP Feature | How We Used It | |-------------|---------------| | Auto API Controllers | ResearchAppService automatically becomes REST API endpoints | | Dependency Injection | Clean registration of agents, tools, orchestrator, Semantic Kernel | | Repository Pattern | IRepository<ResearchRecord> for database operations in MCP tools | | Module System | All agent ecosystem config encapsulated in AgentEcosystemModule | | Entity Framework Core | Research record persistence with code-first migrations | | Built-in Auth | OpenIddict integration for securing agent endpoints | | Health Checks | Monitoring agent ecosystem health |

ABP's single layer template provided us the best .NET groundwork, which had all the enterprise features without any unnecessary complexity for a focused AI project. Of course, the agent architecture (MCP, A2A, ADK) is actually framework-agnostic and can be implemented with any .NET application.

Key Takeaways

1. Protocols Are Complementary, Not Competing

MCP, A2A, and ADK solve different problems. Using them together creates a complete agent system:

• MCP: Standardize tool access
• A2A: Standardize inter-agent communication
• ADK: Standardize agent orchestration

2. Start Simple, Scale Later

Our approach runs all of that in a single process, which is in-process A2A. Using A2A allowed us to design the code so that each agent can be extracted into its own microservice later on without affecting the code logic.

3. Shared State > Message Passing (For Simple Cases)

ADK's AgentContext with shared state is simpler and faster than A2A message passing for in-process scenarios. Use A2A when agents need to run as separate services.

4. MCP is the Real Game-Changer

The ability to define tools once and have any agent use them — with automatic discovery and structured invocations — eliminates enormous amounts of boilerplate code.

5. LLM Abstraction is Critical

Using Semantic Kernel's IChatCompletionService lets you swap between Azure OpenAI, OpenAI, Ollama, or any provider without touching agent code.

What's Next?

This project demonstrates the foundation of a multi-agent system. Future enhancements could include:

• Streaming responses — Real-time updates as agents work (A2A supports this)
• More specialized agents — Code analysis, translation, fact-checking agents
• Distributed deployment — Each agent as a separate microservice with HTTP-based A2A
• Agent marketplace — Discover and integrate third-party agents via A2A Agent Cards
• Human-in-the-loop — Using A2A's InputRequired state for human approval steps
• RAG integration — MCP tools for vector database search

Resources

| Resource | Link | |----------|------| | MCP Specification | modelcontextprotocol.io | | A2A Specification | google.github.io/A2A | | ADK Documentation | google.github.io/adk-docs | | ABP Framework | abp.io | | Semantic Kernel | github.com/microsoft/semantic-kernel | | MCP .NET SDK | NuGet: ModelContextProtocol | | A2A .NET SDK | NuGet: A2A | | Our Source Code | GitHub Repository |

Conclusion

Developing a multi-agent AI system is no longer a futuristic dream; it’s something that can actually be achieved today by using open protocols and available frameworks. In this manner, by using MCP for access to tools, A2A for communicating between agents, and ADK for orchestration, we have actually built a Research Assistant.

ABP Framework and .NET turned out to be an excellent choice, delivering us the infrastructure we needed to implement DI, repositories, auto APIs, and modules, allowing us to work completely on the AI agent architecture.

The era of single LLM calls is ending, and the era of agent ecosystems begins now.

Introduction

Messages can get lost while being processed when you use asynchronous messaging or event handling. The Async Chain of Persistence Pattern makes sure that no message is ever lost from the system by making sure that the message is always stored at every step of the workflow.

The Fundamental Principle of Pattern

The Async Chain of Persistence Pattern guarantees that no message is ever lost by ensuring that the message is always persistently stored at every step of the workflow. This is where the pattern gets its name. A message cannot be removed from its previous location until it is confirmed to be persistently stored in the subsequent stages of the chain.

It is commonly used in event-driven systems and message-driven systems.

Event-Driven versus Message-Driven Systems

To understand the pattern, it's important to know the differences between events and messages.

The Core Difference

Event: Says "something happened", describes the past. Example: OrderPlaced, PaymentCompleted

Message: Says "do this", commands for the future. Example: CreateOrder, SendEmail

| Property | Event | Message | |----------|-------|---------| | Coupling | Loose - no one knows who's listening | Tighter - there's a specific receiver | | Publishing | Pub/Sub - 0-N services listen | Point-to-Point - usually 1 service | | Tense | Past tense, immutable | Present/future tense | | Error Handling | If one consumer fails, others continue | If not processed, system breaks |

Relationship with Async Chain of Persistence

In event-driven systems: Each service receives the event → persists it → publishes a new event

In message-driven systems: At each step, the message is kept safe on queue + disk

In both systems, the goal is the same: no message should be lost!

When Do Messages Get Lost?

There are 3 main scenarios for message loss:

1. While Processing a Message (Receiving a Message)

While processing a message in a reply, by default, there is an automatic acknowledgment and subsequent deletion of a message that is in a queue. But in cases where there is a fatal or unrecoverable error in the message processing operation or a service instance crashes, this message gets lost.

2. Message Broker Crashes

In the majority of message brokers, the default option for the message persistence state is set to nonpersisting. In other words, the message will be held in the memory of the message broker without any persistence. It has been used for the purpose of obtaining rapid responses and improved throughput. However, in the event of failure of the message broker process, the nonpersistent message will be lost permanently.

3. Event Chaining

In event-driven systems, an event is published as a derived message after an operation is done by a service. Message loss in two ways is possible in this scenario:

1. Risk of Asynchronous Send: The publish operation is often carried out using the asynchronous send feature. When a fatal error takes place prior to the receipt of acknowledgment of the message publish operation by the publish services, it becomes difficult to determine if the message has been successfully transmitted to the message broker.
2. Transaction Coordination: In case an error is detected after the commit of the database but before the derived event is published, the derived event might be lost.

Implementing the Pattern: 4 Critical Steps

Four critical steps are required to implement the Async Chain of Persistence Pattern:

1. Message Persistence

The initial step to ensure that there are no lost messages is to specify the messages as PERSISTENT: When the message broker receives the message, it is saved on disk.

var delivery_mode = PERSISTENT
var producer = create_producer(delivery_mode)

// All sent messages are persisted on the message broker
producer.send_message(APPLY_PAYMENT)

// Alternatively
var delivery_mode = PERSISTENT
var producer = create_producer()
producer.send_message(APPLY_PAYMENT, delivery_mode)

With this approach, even if the message broker crashes, all messages will still be there when it comes back up.

2. Client Acknowledgement Mode

Instead, client-acknowledgement mode needs to be employed. When a message is received in this mode, that message will be retained in the queue until a proper acknowledgment from the processing service has been made. Instead of "auto acknowledge" mode, "client-acknowledgement" mode

Client acknowledgement mode ensures that the message is not lost while processing by the service. When a fatal error is detected during message processing, the service exits without sending an acknowledgement message and thus results in a message redispatched.

Important Note: The message has to be acknowledged while the message processing operation is completed so that a repeat message will not be processed.

3. Synchronous Send

The synchronous send must be preferred over the asynchronous send.

Although it takes longer to send via synchronous send, since it's a blocking call, it ensures that the message broker received and persisted the message on disk.

// Blocking call to publish the derived event
var ack = publish_event(PAYMENT_APPLIED)
if (ack not_successful) {
   retry_or_persist(PAYMENT_APPLIED)
}

With this approach, the risk of message loss during event chaining is eliminated.

4. Last Participant Support

This is the most complex step of the Async Chain of Persistence pattern. It determines when the message should be acknowledged.

For Message-Driven Systems:

var message = receive_message()
process_message(message)
database.commit()
message.acknowledge()

Recommended order: commit first, ack last. Otherwise, if the database operation fails, the message will be lost because it has already been removed from the queue.

For Event-Driven Systems

In event-driven systems, there are two distinct parties involved: one that acknowledges an event and another that publishes the event that’s been derived. The party that publishes the event that’s been derived should be treated as “last participant.”

var event = receive_event()
process_event(event)
database.commit()
message.acknowledge()

var ack = publish_event(PAYMENT_APPLIED)
if (ack not_successful) {
   retry_or_persist(PAYMENT_APPLIED)
}

In this sequence, the original event is acknowledged after it is completed. If publishing the derived event fails, it can be retried or persisted for later delivery.

Trade-offs

Advantages

Preventing Message Loss: The major benefit of this pattern is that it doesn't let a message get lost while messages are under processing. This issue, being a serious concern in asynchronous systems, is ruled out due to the pattern.

Disadvantages

1. Possible Duplicate Messages

Enabling the client-acknowledgement mode can result in the processing of the same message multiple times. If the service instance fails after the database commit but before the message could be acknowledged, the message will be repeated and duplicates can be processed.

Solution: In order to determine whether the arriving messages are previously processed or not, the message IDs can be logged and traced back. This also has the drawback of requiring one extra read operation per message in the system.

2. Performance and Throughput

It has also been noted that the time duration in which the persistent message takes to be sent from the message broker could be up to four times longer than in the nonpersistent message transmission.

Persisted messages also affect performance in terms of sending and reading the message. It is also common for message brokers to maintain message data in their memory for efficient reading, but there is no assurance that messages will always be resident in memory, depending on memory size, among other factors.

3. Impact of Synchronous Send

Because a synchronous send makes a blocking call until a confirmation is received, there is no other work that can be accomplished before a confirmation is received from the broker for a synchronous send. A persisted message makes this even more apparent.

4. Overall Scalability

This is because, upon receipt, the message broker has to spend more time persisting messages to disk, thus negatively affecting scalability. Persistent messages always give lower total throughput, which can limit scalability under high usage loads and high message volumes.

Conclusion

The Async Chain of Persistence Pattern provides a powerful solution for preventing message loss. Although it has negative effects on performance, throughput, and scalability, these trade-offs are generally acceptable in systems where data loss is critical.

Before implementing the pattern, carefully analyze your system requirements:

• How critical is message loss?
• What are the performance and throughput requirements?
• How should the system behave in case of duplicate processing?

The answers to these questions will help you determine whether the Async Chain of Persistence Pattern is suitable for your system.

Sample Project

To see an example project where this pattern is implemented, you can check out the repository:

🔗 GitHub Repository

We are pleased to announce that Server-Side Rendering (SSR) has become available for ABP Framework Angular applications! This highly requested feature brings major gains in performance, SEO, and user experience to your Angular applications based on ABP Framework.

What is Server-Side Rendering (SSR)?

Server-Side Rendering refers to an approach which renders your Angular application on the server as opposed to the browser. The server creates the complete HTML for a page and sends it to the client, which can then show the page to the user. This poses many advantages over traditional client-side rendering.

Why SSR Matters for ABP Angular Applications

Improved Performance

• Quicker visualization of the first contentful paint (FCP): Because prerendered HTML is sent over from the server, users will see content quicker.
• Better perceived performance: Even on slower devices, the page will be displaying something sooner.
• Less JavaScript parsing time: For example, the initial page load will not require parsing and executing a large bundle of JavaScript.

Enhanced SEO

• Improved indexing by search engines: Search engine bots are able to crawl and index your content quicker.
• Improved rankings in search: The quicker the content loads and the easier it is to access, the better your SEO score.
• Preview when sharing on social channels: Rich previews with the appropriate meta tags are generated when sharing links on social platforms.

Better User Experience

• Support for low bandwidth: Users with slower Internet connections will have a better experience
• Progressive enhancement: Users can start accessing the content before JavaScript has loaded
• Better accessibility: Screen readers and other assistive technologies can access the content immediately

Getting Started with SSR

Adding SSR to an Existing Project

You can easily add SSR support to your existing ABP Angular application using the Angular CLI with ABP schematics:

Adds SSR configuration to your project

ng generate @abp/ng.schematics:ssr-add

Short form

ng g @abp/ng.schematics:ssr-add

If you have multiple projects in your workspace, you can specify which project to add SSR to:

ng g @abp/ng.schematics:ssr-add --project=my-project

If you want to skip the automatic installation of dependencies:

ng g @abp/ng.schematics:ssr-add --skip-install

What Gets Configured

When you add SSR to your ABP Angular project, the schematic automatically:

1. Installs necessary dependencies: Adds @angular/ssr and related packages
2. Creates Server Configuration: Creates server.ts and related files
3. Updates Project Structure:
   • Creates main.server.ts to bootstrap the server
   • Adds app.config.server.ts for standalone apps (or app.module.server.ts for NgModule apps)
   • Configures server routes in app.routes.server.ts
4. Updates Build Configuration: updates angular.json to include:
   • a serve-ssr target for local SSR development
   • a prerender target for static site generation
   • Proper output paths for browser and server bundles

Supported Configurations

The ABP SSR schematic supports both modern and legacy Angular build configurations:

Application Builder (Suggested)

• The new @angular-devkit/build-angular:application builder
• Optimized for Angular 17+ apps
• Enhanced performance and smaller bundle sizes

Server Builder (Legacy)

• The original @angular-devkit/build-angular:server builder
• Designed for legacy Angular applications
• Compatible with legacy applications

Running Your SSR Application

After adding SSR to your project, you can run your application in SSR mode:

# Development mode with SSR
ng serve

# Or specifically target SSR development server
npm run serve:ssr

# Build for production
npm run build:ssr

# Preview production build
npm run serve:ssr:production

Important Considerations

Browser-Only APIs

Some browser APIs are not available on the server. Use platform checks to conditionally execute code:

import { isPlatformBrowser } from '@angular/common';
import { PLATFORM_ID, inject } from '@angular/core';

export class MyComponent {
  private platformId = inject(PLATFORM_ID);
  
  ngOnInit() {
    if (isPlatformBrowser(this.platformId)) {
      // Code that uses browser-only APIs
      console.log('Running in browser');
      localStorage.setItem('key', 'value');
    }
  }
}

Storage APIs

localStorage and sessionStorage are not accessible on the server. Consider using:

• Cookies for server-accessible data.
• The state transfer API for hydration.
• ABP's built-in storage abstractions.

Third-Party Libraries

Please ensure that any third-party libraries you use are compatible with SSR. These libraries can require:

• Dynamic imports for browser-only code.
• Platform-specific service providers.
• Custom Angular Universal integration.

ABP Framework Integration

The SSR implementation is natively integrated with all of the ABP Framework features:

• Authentication & Authorization: The OAuth/OpenID Connect flow functions seamlessly with ABP
• Multi-tenancy: Fully supports tenant resolution and switching
• Localization: Server-side rendering respects the locale
• Permission Management: Permission checks work on both server and client
• Configuration: The ABP configuration system is SSR-ready

Performance Tips

1. Utilize State Transfer: Send data from server to client to eliminate redundant HTTP requests
2. Optimize Images: Proper image loading strategies, such as lazy loading and responsive images.
3. Cache API Responses: At the server, implement proper caching strategies.
4. Monitor Bundle Size: Keep your server bundle optimized
5. Use Prerendering: The prerender target should be used for static content.

Conclusion

Server-side rendering can be a very effective feature in improving your ABP Angular application's performance, SEO, and user experience. Our new SSR schematic will make it easier than ever to add SSR to your project.

Try it today and let us know what you think!

Angular 21 introduces one of the most exciting developments in the modern edition of Angular: Signal-Based Forms. Built directly on the reactive foundation of Angular signals, this new experimental API provides a cleaner, more intuitive, strongly typed, and ergonomic approach for managing form state—without the heavy boilerplate of Reactive Forms.

⚠️ Important: Signal Forms are experimental. Their API can change. Avoid using them in critical production scenarios unless you understand the risks.

Despite this, Signal Forms clearly represent Angular’s future direction.

Why Signal Forms?

Traditionally in Angular, building forms has involved several concerns:

• Tracking values
• Managing UI interaction states (touched, dirty)
• Handling validation
• Keeping UI and model in sync

Reactive Forms solved many challenges but introduced their own:

• Verbosity FormBuilder API
• Required subscriptions (valueChanges)
• Manual cleaning
• Difficult nested forms
• Weak type-safety

Signal Forms solve these problems through:

1." Automatic synchronization
2." Full type safety
3." Schema-based validation
4." Fine-grained reactivity
5." Drastically reduced boilerplate
6." Natural integration with Angular Signals

1. Form Models — The Core of Signal Forms

A form model is simply a writable signal holding the structure of your form data.

import { Component, signal } from '@angular/core';
import { form, Field } from '@angular/forms/signals';

@Component({
  selector: 'app-login',
  imports: [Field],
  template: `
    <input type="email" [field]="loginForm.email" />
    <input type="password" [field]="loginForm.password" />
  `,
})
export class LoginComponent {
  loginModel = signal({
    email: '',
    password: '',
  });

  loginForm = form(this.loginModel);
}

Calling form(model) creates a Field Tree that maps directly to your model.

2. Achieving Full Type Safety

Although TypeScript can infer types from object literals, defining explicit interfaces provides maximum safety and better IDE support.

interface LoginData {
  email: string;
  password: string;
}

loginModel = signal<LoginData>({
  email: '',
  password: '',
});

loginForm = form(loginModel);

Now:

• loginForm.email → FieldTree<string>
• Accessing invalid fields like loginForm.username results in compile-time errors

This level of type safety surpasses Reactive Forms.

3. Reading Form Values

Read from the model (entire form):

onSubmit() {
  const data = this.loginModel();
  console.log(data.email, data.password);
}

Read from an individual field:

<p>Current email: {{ loginForm.email().value() }}</p>

Each field exposes:

• value()
• valid()
• errors()
• dirty()
• touched()

All as signals.

4. Updating Form Models Programmatically

Signal Forms allow three update methods.

1. Replace the entire model

this.userModel.set({
  name: 'Alice',
  email: 'alice@example.com',
});

2. Patch specific fields

this.userModel.update(prev => ({
  ...prev,
  email: newEmail,
}));

3. Update a single field

this.userForm.email().value.set('');

This eliminates the need for:

• patchValue()
• setValue()
• formGroup.get('field')

5. Automatic Two-Way Binding With [field]

The [field] directive enables perfect two-way data binding:

<input [field]="userForm.name" />

How it works:

• User input → Field state → Model
• Model updates → Field state → Input UI

No subscriptions.
No event handlers.
No boilerplate.

Reactive Forms could never achieve this cleanly.

6. Nested Models and Arrays

Models can contain nested object structures:

userModel = signal({
  name: '',
  address: {
    street: '',
    city: '',
  },
});

Access fields easily:

<input [field]="userForm.address.street" />

Arrays are also supported:

orderModel = signal({
  items: [
    { product: '', quantity: 1, price: 0 }
  ]
});

Field state persists even when array items move, thanks to identity tracking.

7. Schema-Based Validation

Validation is clean and centralized:

import { required, email } from '@angular/forms/signals';

const model = signal({ email: '' });

const formRef = form(model, {
  email: [required(), email()],
});

Field validation state is reactive:

formRef.email().valid()
formRef.email().errors()
formRef.email().touched()

Validation no longer scatters across components.

8. When Should You Use Signal Forms?

New Angular 21+ apps

Signal-first architecture is the new standard.

Teams wanting stronger type safety

Every field is exactly typed.

Devs tired of Reactive Form boilerplate

Signal Forms drastically simplify code.

Complex UI with computed reactive form state

Signals integrate perfectly.

❌ Avoid if:

• You need long-term stability
• You rely on mature Reactive Forms features
• Your app must avoid experimental APIs

9. Reactive Forms vs Signal Forms

| Feature | Reactive Forms | Signal Forms | |--------|----------------|--------------| | Boilerplate | High | Very low | | Type-safety | Weak | Strong | | Two-way binding | Manual | Automatic | | Validation | Scattered | Centralized schema | | Nested forms | Verbose | Natural | | Subscriptions | Required | None | | Change detection | Zone-heavy | Fine-grained |

Signal Forms feel like the "modern Angular mode," while Reactive Forms increasingly feel legacy.

10. Full Example: Login Form

@Component({
  selector: 'app-login',
  imports: [Field],
  template: `
    <form (ngSubmit)="submit()">
      <input type="email" [field]="form.email" />
      <input type="password" [field]="form.password" />
      <button>Login</button>
    </form>
  `,
})
export class LoginComponent {
  model = signal({ email: '', password: '' });
  form = form(this.model);

  submit() {
    console.log(this.model());
  }
}

Minimal. Reactive. Completely type-safe.

Conclusion

Signal Forms in Angular 21 represent a big step forward:

• Cleaner API
• Stronger type safety
• Automatic two-way binding
• Centralized validation
• Fine-grained reactivity
• Dramatically better developer experience

Although these are experimental, they clearly show the future of Angular's form ecosystem. Once you get into using Signal Forms, you may never want to use Reactive Forms again.

Introduction

In modern distributed systems, synchronizing access to common resources among numerous instances is a critical problem. Whenever lots of servers or processes concurrently attempt to update the same resource simultaneously, race conditions can lead to data corruption, redundant work, and inconsistent state. Throughout the implementation of the ABP framework, we encountered and overcame this exact same problem with assistance from a stable distributed locking mechanism. In this post, we will present our experience and learnings when implementing this solution, so you can understand when and why you would need distributed locking in your ASP.NET Core applications.

Problem

Suppose you are running an e-commerce application deployed on multiple servers for high availability. A customer places an order, which kicks off a background job that reserves inventory and charges payment. If not properly synchronized, the following is what can happen:

Race Conditions in Multi-Instance Deployments

When your ASP.NET Core application is scaled horizontally with multiple instances, each instance works independently. If two instances simultaneously perform the same operation—like deducting inventory, generating invoice numbers, or processing a refund—you can end up with:

• Duplicate operations: The same payment processed twice
• Data inconsistency: Inventory count becomes negative or incorrect
• Lost updates: One instance's changes overwrite another's
• Sequential ID conflicts: Two instances generate the same invoice number

Background Job Processing

Background work libraries like Quartz.NET or Hangfire usually run on multiple workers. Without distributed locking:

• Multiple workers can choose the same task
• Long-running processes can be executed parallel when they should be executed in a sequence
• Jobs that depend on exclusive resource access can corrupt shared data

Cache Invalidation and Refresh

When distributed caching is employed, there can be multiple instances that simultaneously identify a cache miss and attempt to rebuild the cache, leading to:

• High database load owing to concurrent rebuild cache requests
• Race conditions under which older data overrides newer data
• wasted computational resources

Rate Limiting and Throttling

Enforcing rate limits across multiple instances of the application requires coordination. If there is no distributed locking, each instance has its own limits, and global rate limits cannot be enforced properly.

The root issue is simple: the default C# locking APIs (lock, SemaphoreSlim, Monitor) work within a process in isolation. They will not assist with distributed cases where coordination must take place across servers, containers, or cloud instances.

Solutions

Several approaches exist for implementing distributed locking in ASP.NET Core applications. Let's explore the most common solutions, their trade-offs, and why we chose our approach for ABP.

1. Database-Based Locking

Using your existing database to place locks by inserting or updating rows with distinctive values.

Pros:

• No additional infrastructure required
• Works with any relational database
• Transactions provide ACID guarantees

Cons:

• Database round-trip performance overhead
• Can lead to database contention under high load
• Must be controlled to prevent orphaned locks
• Not suited for high-frequency locking scenarios

When to use: Small-scale applications where you do not wish to add additional infrastructure, and lock operations are low frequency.

2. Redis-Based Locking

Redis has atomic operations that make it excellent at distributed locking, using commands such as SET NX (set if not exists) with expiration. Pros:

• Low latency and high performance

• Expiration prevents lost locks built-in

• Well-established with tested patterns (Redlock algorithm)

• Works well for high-throughput use cases Cons:

• Requires Redis infrastructure

• Network partitions might be an issue

• One Redis instance is a single point of failure (although Redis Cluster reduces it) Resources:

• Redis Distributed Locks Documentation

• Redlock Algorithm When to use: Production applications with multiple instances where performance is critical, especially if you are already using Redis as a caching layer.

3. Azure Blob Storage Leases

Azure Blob Storage offers lease functionality which can be utilized for distributed locks.

Pros:

• Part of Azure, no extra infrastructure
• Lease expiration automatically
• Low-frequency locks are economically viable

Cons:

• Azure-specific, not portable
• Latency greater than Redis
• Azure cloud-only projects

When to use: Azure-native applications with low-locking frequency where you need to minimize moving parts.

4. etcd or ZooKeeper

Distributed coordination services designed from scratch to accommodate consensus and locking.

Pros:

• Designed for distributed coordination
• Strong consistency guaranteed
• Robust against network partitions

Cons:

• Difficulty in setting up the infrastructure
• Excess baggage for most applications
• Steep learning curve

Use when: Large distributed systems with complex coordination require more than basic locking.

Our Choice: Abstraction with Multiple Implementations

For ABP, we chose to use an abstraction layer with support for multibackend. This provides flexibility to the developers so that they can choose the best implementation depending on their infrastructure. Our default implementations include support for:

• Redis (recommended for most scenarios)
• Database-based locking (for less complicated configurations)
• In-memory single-instance and development locks

We started with Redis because it offers the best tradeoff between ease of operation, reliability, and performance for distributed cases. But abstraction prevents applications from becoming technology-dependent, and it's easier to start simple and expand as needed.

Implementation

Let's implement a simplified distributed locking mechanism using Redis and StackExchange.Redis. This example shows the core concepts without ABP's framework complexity.

First, install the required package:

dotnet add package StackExchange.Redis

Here's a basic distributed lock implementation:

public interface IDistributedLock
{
    Task<IDisposable?> TryAcquireAsync(
        string resource,
        TimeSpan expirationTime,
        CancellationToken cancellationToken = default);
}

public class RedisDistributedLock : IDistributedLock
{
    private readonly IConnectionMultiplexer _redis;
    private readonly ILogger<RedisDistributedLock> _logger;

    public RedisDistributedLock(
        IConnectionMultiplexer redis,
        ILogger<RedisDistributedLock> logger)
    {
        _redis = redis;
        _logger = logger;
    }

    public async Task<IDisposable?> TryAcquireAsync(
        string resource,
        TimeSpan expirationTime,
        CancellationToken cancellationToken = default)
    {
        var db = _redis.GetDatabase();
        var lockKey = $"lock:{resource}";
        var lockValue = Guid.NewGuid().ToString();

        // Try to acquire the lock using SET NX with expiration
        var acquired = await db.StringSetAsync(
            lockKey,
            lockValue,
            expirationTime,
            When.NotExists);

        if (!acquired)
        {
            _logger.LogDebug(
                "Failed to acquire lock for resource: {Resource}",
                resource);
            return null;
        }

        _logger.LogDebug(
            "Lock acquired for resource: {Resource}",
            resource);

        return new RedisLockHandle(db, lockKey, lockValue, _logger);
    }

    private class RedisLockHandle : IDisposable
    {
        private readonly IDatabase _db;
        private readonly string _lockKey;
        private readonly string _lockValue;
        private readonly ILogger _logger;
        private bool _disposed;

        public RedisLockHandle(
            IDatabase db,
            string lockKey,
            string lockValue,
            ILogger logger)
        {
            _db = db;
            _lockKey = lockKey;
            _lockValue = lockValue;
            _logger = logger;
        }

        public void Dispose()
        {
            if (_disposed) return;

            try
            {
                // Only delete if we still own the lock
                var script = @"
                    if redis.call('get', KEYS[1]) == ARGV[1] then
                        return redis.call('del', KEYS[1])
                    else
                        return 0
                    end";

                _db.ScriptEvaluate(
                    script,
                    new RedisKey[] { _lockKey },
                    new RedisValue[] { _lockValue });

                _logger.LogDebug("Lock released for key: {LockKey}", _lockKey);
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex,
                    "Error releasing lock for key: {LockKey}",
                    _lockKey);
            }
            finally
            {
                _disposed = true;
            }
        }
    }
}

Register the service in your Program.cs:

builder.Services.AddSingleton<IConnectionMultiplexer>(sp =>
{
    var configuration = ConfigurationOptions.Parse("localhost:6379");
    return ConnectionMultiplexer.Connect(configuration);
});

builder.Services.AddSingleton<IDistributedLock, RedisDistributedLock>();

Now you can use distributed locking in your services:

public class OrderService
{
    private readonly IDistributedLock _distributedLock;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IDistributedLock distributedLock,
        ILogger<OrderService> logger)
    {
        _distributedLock = distributedLock;
        _logger = logger;
    }

    public async Task ProcessOrderAsync(string orderId)
    {
        var lockResource = $"order:{orderId}";
        
        // Try to acquire the lock with 30-second expiration
        await using var lockHandle = await _distributedLock.TryAcquireAsync(
            lockResource,
            TimeSpan.FromSeconds(30));

        if (lockHandle == null)
        {
            _logger.LogWarning(
                "Could not acquire lock for order {OrderId}. " +
                "Another process might be processing it.",
                orderId);
            return;
        }

        // Critical section - only one instance will execute this
        _logger.LogInformation("Processing order {OrderId}", orderId);
        
        // Your order processing logic here
        await Task.Delay(1000); // Simulating work
        
        _logger.LogInformation(
            "Order {OrderId} processed successfully",
            orderId);
        
        // Lock is automatically released when lockHandle is disposed
    }
}

Key Implementation Details

Lock Key Uniqueness: Use hierarchical, descriptive keys (order:12345, inventory:product-456) to avoid collisions.

Lock Value: We use a single distinct GUID as the lock value. This ensures only the lock owner can release it, excluding unintentional deletion by expired locks or other operations.

Automatic Expiration: Always provide an expiration time to prevent deadlocks when a process halts with an outstanding lock.

Lua Script for Release: Releasing uses a Lua script to atomically check ownership and delete the key. This prevents releasing a lock that has already timed out and is reacquired by another process.

Disposal Pattern: With IDisposable and await using, one ensures that the lock is released regardless of the exception that occurs.

Handling Lock Acquisition Failures

Depending on your use case, you have several options when lock acquisition fails:

// Option 1: Return early (shown above)
if (lockHandle == null)
{
    return;
}

// Option 2: Retry with timeout
var retryCount = 0;
var maxRetries = 3;
IDisposable? lockHandle = null;

while (lockHandle == null && retryCount < maxRetries)
{
    lockHandle = await _distributedLock.TryAcquireAsync(
        lockResource,
        TimeSpan.FromSeconds(30));
    
    if (lockHandle == null)
    {
        retryCount++;
        await Task.Delay(TimeSpan.FromMilliseconds(100 * retryCount));
    }
}

if (lockHandle == null)
{
    throw new InvalidOperationException("Could not acquire lock after retries");
}

// Option 3: Queue for later processing
if (lockHandle == null)
{
    await _queueService.EnqueueForLaterAsync(orderId);
    return;
}

This is a good foundation for distributed locking in ASP.NET Core applications. It addresses the most common scenarios and edge cases, but production can call for more sophisticated features like lock re-renewal for long-running operations or more sophisticated retry logic.

Conclusion

Distributed locking is a necessity for data consistency and prevention of race conditions in new, scalable ASP.NET Core applications. As we've discussed, the problem becomes unavoidable as soon as you move beyond single-instance deployments to horizontally scaled multi-server, container, or background job worker deployments.

We examined several of them, from database-level locks to Redis, Azure Blob Storage leases, and coordination services. Each has its place, but Redis-based locking offers the best balance of performance, reliability, and ease in most situations. The example implementation we provided shows how to implement a well-crafted distributed locking mechanism with minimal dependence on other libraries.

Whether you implement your own solution or utilize a framework like ABP, familiarity with the concepts of distributed locking will help you build more stable and scalable applications. We hope by sharing our experience, we can keep you from falling into typical pitfalls and have distributed locking properly implemented on your own projects.

Introduction

In this article, we are going to discuss how to secure sensitive data in ABP Framework projects using AWS Secrets Manager and explain various aspects and concepts of secret data management. We will explain step-by-step AWS Secrets Manager integration.

What is the Problem?

Modern applications must store sensitive data such as API keys, database connection strings, OAuth client credentials, and other similar sensitive data. These are at the center of functionality but if stored in the wrong place can be massive security issues.

At build time, the first place that comes to mind is usually appsettings.json. This is a configuration file; it is not a secure place to store secret information, especially in production.

Common Security Risks:

• Plain text storage: Plain text storage of passwords
• Exposure to version control: Secrets are rendered encrypted in Git repositories
• No access control: Anyone who has file access can see the secrets
• No rotation: We must change them manually
• No audit trail: Who accessed which secret when is not known

.NET User Secrets Tool vs AWS Secrets Manager

User Secrets (.NET Secret Manager Tools) is a dev environment only, local file-based solution that keeps sensitive information out of the repository.

AWS Secrets Manager is production. It's a centralized, encrypted, and audited secret management service.

| Feature | User Secrets (Dev) | AWS Secrets Manager (Prod) | | ---------------------- | ---------------------------- | ------------------------------ | | Scope | Local developer machine | All environments (dev/stage/prod) | | Storage | JSON in user profile | Managed service (centralized) | | Encryption | None (plain text file) | Encrypted with KMS | | Access Control | OS file permissions | IAM policies | | Rotation | None | Yes (automatic) | | Audit / Traceability | None | Yes (CloudTrail) | | Typical Usage | Quick dev outside repo | Production secret management |

AWS Secrets Manager

Especially designed to securely store and handle sensitive and confidential data for our applications. It even supports features such as secret rotation, replication, and many more.

AWS Secrets Manager offers a trial of 30 days. After that, there is a $0.40 USD/month charge per stored secret. There is also a $0.05 USD fee per 10,000 API requests.

Key Features:

• Automatic encryption: KMS automatic encryption
• Automatic rotation: Scheduled secret rotation
• Fine-grained access control: IAM fine-grained access control
• Audit logging: Full audit logging with CloudTrail
• Cross-region replication: Cross-region replication
• API integration: Programmatic access support

Step 1: AWS Secrets Manager Setup

1.1 Creating a Secret in AWS Console

First, search for the Secrets Manager service in the AWS Management Console.

1. AWS Console → Secrets Manager → Store a new secret

2. Select Secret type:

   • Other type of secret (For custom key-value pairs)
   • Credentials for RDS database (For databases)
   • Credentials for DocumentDB database
   • Credentials for Redshift cluster

3. Enter Secret value:

{
  "ConnectionString": "Server=myserver;Database=mydb;User Id=myuser;Password=mypassword;"
}

4. Set Secret name: prod/ABPAWSTest/ConnectionString
5. Add Description: "ABP Framework connection string for production"
6. Choose Encryption key (default KMS key is sufficient)
7. Configure Automatic rotation settings (optional)

1.2 IAM Permissions

Create an IAM policy for secret access:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "arn:aws:secretsmanager:eu-north-1:588118819172:secret:prod/ABPAWSTest/ConnectionString-*"
        }
    ]
}

Step 2: ABP Framework Project Setup

2.1 NuGet Packages

Add the required AWS packages to your project:

dotnet add package AWSSDK.SecretsManager
dotnet add package AWSSDK.Extensions.NETCore.Setup

2.2 Configuration Files

appsettings.json (Development):

{
  "AWS": {
    "Profile": "default",
    "Region": "eu-north-1",
    "AccessKey": "YOUR_ACCESS_KEY",
    "SecretKey": "YOUR_SECRET_KEY"
  },
  "SecretsManager": {
    "SecretName": "prod/ABPAWSTest/ConnectionString",
    "SecretArn": "arn:aws:secretsmanager:eu-north-1:588118819172:secret:prod/ABPAWSTest/ConnectionString-xtYQxv"
  }
}

appsettings.Production.json (Production):

{
  "AWS": {
    "Region": "eu-north-1"
    // Use environment variables or IAM roles in production
  },
  "SecretsManager": {
    "SecretName": "prod/ABPAWSTest/ConnectionString"
  }
}

2.3 Environment Variables (Production)

export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_DEFAULT_REGION=eu-north-1

Step 3: AWS Integration Implementation

3.1 Program.cs Configuration

using Amazon;
using Amazon.SecretsManager;

public class Program
{
    public async static Task<int> Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);
        
        // AWS Secrets Manager configuration
        var awsOptions = builder.Configuration.GetAWSOptions();
        
        // Read AWS credentials from appsettings
        var accessKey = builder.Configuration["AWS:AccessKey"];
        var secretKey = builder.Configuration["AWS:SecretKey"];
        var region = builder.Configuration["AWS:Region"];
        
        if (!string.IsNullOrEmpty(accessKey) && !string.IsNullOrEmpty(secretKey))
        {
            awsOptions.Credentials = new Amazon.Runtime.BasicAWSCredentials(accessKey, secretKey);
        }
        
        if (!string.IsNullOrEmpty(region))
        {
            awsOptions.Region = RegionEndpoint.GetBySystemName(region);
        }
        
        builder.Services.AddDefaultAWSOptions(awsOptions);
        builder.Services.AddAWSService<IAmazonSecretsManager>();
        
        // ... ABP configuration
        await builder.AddApplicationAsync<YourAppModule>();
        var app = builder.Build();
        
        await app.InitializeApplicationAsync();
        await app.RunAsync();
    }
}

3.2 Secrets Manager Service

Interface:

public interface ISecretsManagerService
{
    Task<string> GetSecretAsync(string secretName);
    Task<T> GetSecretAsync<T>(string secretName) where T : class;
    Task<string> GetConnectionStringAsync();
}

Implementation:

using Amazon.SecretsManager;
using Amazon.SecretsManager.Model;
using Volo.Abp.DependencyInjection;
using System.Text.Json;

public class SecretsManagerService : ISecretsManagerService, IScopedDependency
{
    private readonly IAmazonSecretsManager _secretsManager;
    private readonly IConfiguration _configuration;
    private readonly ILogger<SecretsManagerService> _logger;

    public SecretsManagerService(
        IAmazonSecretsManager secretsManager,
        IConfiguration configuration,
        ILogger<SecretsManagerService> logger)
    {
        _secretsManager = secretsManager;
        _configuration = configuration;
        _logger = logger;
    }

    public async Task<string> GetSecretAsync(string secretName)
    {
        try
        {
            var request = new GetSecretValueRequest
            {
                SecretId = secretName
            };

            var response = await _secretsManager.GetSecretValueAsync(request);
            
            _logger.LogInformation("Successfully retrieved secret: {SecretName}", secretName);
            
            return response.SecretString;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to retrieve secret: {SecretName}", secretName);
            throw;
        }
    }

    public async Task<T> GetSecretAsync<T>(string secretName) where T : class
    {
        var secretValue = await GetSecretAsync(secretName);
        
        try
        {
            return JsonSerializer.Deserialize<T>(secretValue) 
                ?? throw new InvalidOperationException($"Failed to deserialize secret {secretName}");
        }
        catch (JsonException ex)
        {
            _logger.LogError(ex, "Failed to deserialize secret {SecretName}", secretName);
            throw;
        }
    }

    public async Task<string> GetConnectionStringAsync()
    {
        var secretName = _configuration["SecretsManager:SecretName"] 
            ?? throw new InvalidOperationException("SecretsManager:SecretName configuration is missing");
            
        return await GetSecretAsync(secretName);
    }
}

Step 4: Usage Examples

4.1 Using in Application Service

[RemoteService(false)]
public class DatabaseService : ApplicationService
{
    private readonly ISecretsManagerService _secretsManager;
    
    public DatabaseService(ISecretsManagerService secretsManager)
    {
        _secretsManager = secretsManager;
    }
    
    public async Task<string> GetDatabaseConnectionAsync()
    {
        // Get connection string from AWS Secrets Manager
        var connectionString = await _secretsManager.GetConnectionStringAsync();
        
        // Use the connection string
        return connectionString;
    }
    
    public async Task<ApiConfiguration> GetApiConfigAsync()
    {
        // Deserialize JSON secret
        var config = await _secretsManager.GetSecretAsync<ApiConfiguration>("prod/MyApp/ApiConfig");
        
        return config;
    }
}

4.2 DbContext Configuration

public class YourDbContextConfigurer
{
    public static void Configure(DbContextOptionsBuilder<YourDbContext> builder, string connectionString)
    {
        builder.UseSqlServer(connectionString);
    }

    public static void Configure(DbContextOptionsBuilder<YourDbContext> builder, DbConnection connection)
    {
        builder.UseSqlServer(connection);
    }
}

// Usage in Module
public override void ConfigureServices(ServiceConfigurationContext context)
{
    var configuration = context.Services.GetConfiguration();
    var secretsManager = context.Services.GetRequiredService<ISecretsManagerService>();
    
    // Get secret at startup and pass to DbContext
    var connectionString = await secretsManager.GetConnectionStringAsync();
    
    context.Services.AddAbpDbContext<YourDbContext>(options =>
    {
        options.AddDefaultRepositories(includeAllEntities: true);
        options.DbContextOptions.UseSqlServer(connectionString);
    });
}

Step 5: Best Practices & Security

5.1 Security Best Practices

1. Environment-based Configuration:

   • Development: appsettings.json
   • Production: Environment variables or IAM roles

2. Principle of Least Privilege:

   {
     "Effect": "Allow",
     "Action": "secretsmanager:GetSecretValue",
     "Resource": "arn:aws:secretsmanager:region:account:secret:specific-secret-*"
   }
   

3. Secret Rotation:

   • Set up automatic rotation
   • Custom rotation logic with Lambda functions

4. Caching Strategy:

   public class CachedSecretsManagerService : ISecretsManagerService
   {
       private readonly IMemoryCache _cache;
       private readonly SecretsManagerService _secretsManager;
   
       public async Task<string> GetSecretAsync(string secretName)
       {
           var cacheKey = $"secret:{secretName}";
   
           if (_cache.TryGetValue(cacheKey, out string cachedValue))
           {
               return cachedValue;
           }
   
           var value = await _secretsManager.GetSecretAsync(secretName);
   
           _cache.Set(cacheKey, value, TimeSpan.FromMinutes(30));
   
           return value;
       }
   }
   

5.2 Error Handling

public async Task<string> GetSecretWithRetryAsync(string secretName)
{
    const int maxRetries = 3;
    var delay = TimeSpan.FromSeconds(1);
    
    for (int i = 0; i < maxRetries; i++)
    {
        try
        {
            return await GetSecretAsync(secretName);
        }
        catch (AmazonSecretsManagerException ex) when (i < maxRetries - 1)
        {
            _logger.LogWarning(ex, "Retry {Attempt} for secret {SecretName}", i + 1, secretName);
            await Task.Delay(delay);
            delay = TimeSpan.FromMilliseconds(delay.TotalMilliseconds * 2); // Exponential backoff
        }
    }
    
    throw new InvalidOperationException($"Failed to retrieve secret {secretName} after {maxRetries} attempts");
}

5.3 Performance Optimization

public class PerformantSecretsManagerService : ISecretsManagerService
{
    private readonly IAmazonSecretsManager _secretsManager;
    private readonly IMemoryCache _cache;
    private readonly ILogger<PerformantSecretsManagerService> _logger;
    private readonly SemaphoreSlim _semaphore = new(1, 1);

    public async Task<string> GetSecretAsync(string secretName)
    {
        var cacheKey = $"secret:{secretName}";
        
        // Try to get from cache first
        if (_cache.TryGetValue(cacheKey, out string cachedValue))
        {
            return cachedValue;
        }

        // Use semaphore to prevent multiple concurrent requests for the same secret
        await _semaphore.WaitAsync();
        try
        {
            // Double-check pattern
            if (_cache.TryGetValue(cacheKey, out cachedValue))
            {
                return cachedValue;
            }

            // Fetch from AWS
            var value = await GetSecretFromAwsAsync(secretName);
            
            // Cache for 30 minutes
            _cache.Set(cacheKey, value, TimeSpan.FromMinutes(30));
            
            return value;
        }
        finally
        {
            _semaphore.Release();
        }
    }
}

Step 6: Testing & Debugging

6.1 Unit Testing

public class SecretsManagerServiceTests : AbpIntegratedTest<TestModule>
{
    private readonly ISecretsManagerService _secretsManager;
    
    public SecretsManagerServiceTests()
    {
        _secretsManager = GetRequiredService<ISecretsManagerService>();
    }
    
    [Fact]
    public async Task Should_Get_Connection_String()
    {
        // Act
        var connectionString = await _secretsManager.GetConnectionStringAsync();
        
        // Assert
        connectionString.ShouldNotBeNullOrEmpty();
        connectionString.ShouldContain("Server=");
    }
    
    [Fact]
    public async Task Should_Deserialize_Json_Secret()
    {
        // Arrange
        var secretName = "test/json/config";
        
        // Act
        var config = await _secretsManager.GetSecretAsync<TestConfig>(secretName);
        
        // Assert
        config.ShouldNotBeNull();
        config.ApiKey.ShouldNotBeNullOrEmpty();
    }
}

6.2 Mock Implementation for Testing

public class MockSecretsManagerService : ISecretsManagerService, ISingletonDependency
{
    private readonly Dictionary<string, string> _secrets = new()
    {
        ["prod/ABPAWSTest/ConnectionString"] = "Server=localhost;Database=TestDb;Trusted_Connection=true;",
        ["prod/MyApp/ApiKey"] = "test-api-key",
        ["prod/MyApp/Config"] = """{"ApiUrl": "https://api.test.com", "Timeout": 30}"""
    };

    public Task<string> GetSecretAsync(string secretName)
    {
        if (_secrets.TryGetValue(secretName, out var secret))
        {
            return Task.FromResult(secret);
        }
        
        throw new ArgumentException($"Unknown secret: {secretName}");
    }
    
    public async Task<T> GetSecretAsync<T>(string secretName) where T : class
    {
        var json = await GetSecretAsync(secretName);
        return JsonSerializer.Deserialize<T>(json) 
            ?? throw new InvalidOperationException($"Failed to deserialize {secretName}");
    }
    
    public Task<string> GetConnectionStringAsync()
    {
        return GetSecretAsync("prod/ABPAWSTest/ConnectionString");
    }
}

6.3 Integration Testing

public class SecretsManagerIntegrationTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly WebApplicationFactory<Program> _factory;
    private readonly HttpClient _client;

    public SecretsManagerIntegrationTests(WebApplicationFactory<Program> factory)
    {
        _factory = factory;
        _client = _factory.CreateClient();
    }

    [Fact]
    public async Task Should_Connect_To_Database_With_Secret()
    {
        // Arrange & Act
        var response = await _client.GetAsync("/api/health");
        
        // Assert
        response.EnsureSuccessStatusCode();
    }
}

Step 7: Monitoring & Observability

7.1 CloudWatch Metrics

public class MonitoredSecretsManagerService : ISecretsManagerService
{
    private readonly ISecretsManagerService _inner;
    private readonly IMetrics _metrics;
    private readonly ILogger<MonitoredSecretsManagerService> _logger;

    public async Task<string> GetSecretAsync(string secretName)
    {
        using var activity = Activity.StartActivity("SecretsManager.GetSecret");
        activity?.SetTag("secret.name", secretName);
        
        var stopwatch = Stopwatch.StartNew();
        
        try
        {
            var result = await _inner.GetSecretAsync(secretName);
            
            _metrics.Counter("secrets_manager.requests")
                .WithTag("secret_name", secretName)
                .WithTag("status", "success")
                .Increment();
                
            _metrics.Timer("secrets_manager.duration")
                .WithTag("secret_name", secretName)
                .Record(stopwatch.ElapsedMilliseconds);
            
            return result;
        }
        catch (Exception ex)
        {
            _metrics.Counter("secrets_manager.requests")
                .WithTag("secret_name", secretName)
                .WithTag("status", "error")
                .WithTag("error_type", ex.GetType().Name)
                .Increment();
                
            _logger.LogError(ex, "Failed to retrieve secret {SecretName}", secretName);
            throw;
        }
    }
}

7.2 Health Checks

public class SecretsManagerHealthCheck : IHealthCheck
{
    private readonly IAmazonSecretsManager _secretsManager;
    private readonly ILogger<SecretsManagerHealthCheck> _logger;

    public SecretsManagerHealthCheck(
        IAmazonSecretsManager secretsManager,
        ILogger<SecretsManagerHealthCheck> logger)
    {
        _secretsManager = secretsManager;
        _logger = logger;
    }

    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context,
        CancellationToken cancellationToken = default)
    {
        try
        {
            // Try to list secrets to verify connection
            var request = new ListSecretsRequest { MaxResults = 1 };
            await _secretsManager.ListSecretsAsync(request, cancellationToken);
            
            return HealthCheckResult.Healthy("AWS Secrets Manager is accessible");
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "AWS Secrets Manager health check failed");
            return HealthCheckResult.Unhealthy("AWS Secrets Manager is not accessible", ex);
        }
    }
}

// Register in Program.cs
builder.Services.AddHealthChecks()
    .AddCheck<SecretsManagerHealthCheck>("secrets-manager");

Step 8: Advanced Scenarios

8.1 Dynamic Configuration Reload

public class DynamicSecretsConfigurationProvider : ConfigurationProvider, IDisposable
{
    private readonly ISecretsManagerService _secretsManager;
    private readonly Timer _reloadTimer;
    private readonly string _secretName;

    public DynamicSecretsConfigurationProvider(
        ISecretsManagerService secretsManager,
        string secretName)
    {
        _secretsManager = secretsManager;
        _secretName = secretName;
        
        // Reload every 5 minutes
        _reloadTimer = new Timer(ReloadSecrets, null, TimeSpan.Zero, TimeSpan.FromMinutes(5));
    }

    private async void ReloadSecrets(object state)
    {
        try
        {
            var secretValue = await _secretsManager.GetSecretAsync(_secretName);
            var config = JsonSerializer.Deserialize<Dictionary<string, string>>(secretValue);
            
            Data.Clear();
            foreach (var kvp in config)
            {
                Data[kvp.Key] = kvp.Value;
            }
            
            OnReload();
        }
        catch (Exception ex)
        {
            // Log error but don't throw to avoid crashing the timer
            Console.WriteLine($"Failed to reload secrets: {ex.Message}");
        }
    }

    public void Dispose()
    {
        _reloadTimer?.Dispose();
    }
}

8.2 Multi-Region Failover

public class MultiRegionSecretsManagerService : ISecretsManagerService
{
    private readonly List<IAmazonSecretsManager> _clients;
    private readonly ILogger<MultiRegionSecretsManagerService> _logger;

    public MultiRegionSecretsManagerService(
        IConfiguration configuration,
        ILogger<MultiRegionSecretsManagerService> logger)
    {
        _logger = logger;
        _clients = new List<IAmazonSecretsManager>();
        
        // Create clients for multiple regions
        var regions = new[] { "us-east-1", "us-west-2", "eu-west-1" };
        foreach (var region in regions)
        {
            var config = new AmazonSecretsManagerConfig
            {
                RegionEndpoint = RegionEndpoint.GetBySystemName(region)
            };
            _clients.Add(new AmazonSecretsManagerClient(config));
        }
    }

    public async Task<string> GetSecretAsync(string secretName)
    {
        Exception lastException = null;
        
        foreach (var client in _clients)
        {
            try
            {
                var request = new GetSecretValueRequest { SecretId = secretName };
                var response = await client.GetSecretValueAsync(request);
                
                _logger.LogInformation("Retrieved secret from region {Region}", 
                    client.Config.RegionEndpoint.SystemName);
                
                return response.SecretString;
            }
            catch (Exception ex)
            {
                lastException = ex;
                _logger.LogWarning(ex, "Failed to retrieve secret from region {Region}", 
                    client.Config.RegionEndpoint.SystemName);
            }
        }
        
        throw new InvalidOperationException(
            "Failed to retrieve secret from all regions", lastException);
    }
}

Conclusion

AWS Secrets Manager integration with ABP Framework significantly enhances the security of your applications. With this integration:

Centralized Secret Management: All secrets are managed centrally Better Security: Encryption through KMS and access control through IAM Audit Trail: Complete recording of who accessed which secret when Automatic Rotation: Secrets can be rotated automatically High Availability: AWS high availability guarantee Easy Integration: Native integration with ABP Framework Cost Effective: Pay only for what you use Scalable: Scales with your application needs

With this post, you can securely utilize AWS Secrets Manager in your ABP Framework applications and bid farewell to secret management concerns in production.

Key Benefits:

• Developer Productivity: No hardcoded secrets in config files
• Operational Excellence: Automation of rotation and monitoring
• Security Compliance: Meet enterprise security requirements
• Peace of Mind: Professional-grade secret management

Additional Resources

• AWS Secrets Manager Documentation
• ABP Framework Documentation
• AWS SDK for .NET
• AWS Security Best Practices
• Sample Project Repository

Introduction

With microservice architecture, each service develops and ships independently at its own pace, and clients infrequently update in lockstep. Backward compatibility means that when you release new versions, current consumers continue to function without changing code. This article provides a practical, 6–7 minute tutorial specific to .NET developers.

What Counts as “Breaking”? (and what doesn’t)

A change is breaking if a client that previously conformed can fail at compile time or runtime, or exhibit different business‑critical behavior, without changing that client in any way. In other words: if an old client needs to be altered in order to continue functioning as it did, your change is breaking.

Examples of breaking changes

• Deleting or renaming an endpoint or modifying its URL/route.
• Making an existing field required (e.g., requiring address).
• Data type or format changes (e.g., price: string → price: number, or date format changes).
• Altering default behavior or ordering that clients implicitly depend on (hidden contracts).
• Changing the error model or HTTP status codes in a manner that breaks pre-existing error handling.
• Renaming fields or making optional fields required in requests or responses.
• Reinterpreting semantics (e.g., status="closed" formerly included archived items, but no longer does).

Examples of non‑breaking changes

• Optional fields or query parameters can be added (clients may disregard them).
• Adding new enum values (if the clients default to a safe behavior for unrecognized values).
• Adding a new endpoint while leaving the previous one unchanged.
• Performance enhancements that leave input/output unchanged.
• Including metadata (e.g., pagination links) without changing the current payload shape.

Golden rule: Old clients should continue to work exactly as they did before—without any changes.

Versioning Strategy

Versioning is your master control lever for managing change. Typical methods:

1. URI Segment (simplest)

GET /api/v1/orders
GET /api/v2/orders

Pros: Cache/gateway‑friendly; explicit in docs. Cons: URL noise.

2. Header‑Based

GET /api/orders
x-api-version: 2.0

Pros: Clean URLs; multiple reader support. Cons: Needs proxy/CDN rules.

3. Media Type Accept: application/json;v=2

Pros: Semantically accurate.
Cons: More complicated to test and implement.
Recommendation: For the majority of teams, favor URI segments, with an optional x-api-version header for flexibility.

Quick Setup in ASP.NET Core (Asp.Versioning)

// Program.cs
using Asp.Versioning;

builder.Services.AddControllers();
builder.Services.AddApiVersioning(o =>
{
    o.DefaultApiVersion = new ApiVersion(1, 0);
    o.AssumeDefaultVersionWhenUnspecified = true;
    o.ReportApiVersions = true; // response header: api-supported-versions
    o.ApiVersionReader = ApiVersionReader.Combine(
        new UrlSegmentApiVersionReader(),
        new HeaderApiVersionReader("x-api-version")
    );
});

builder.Services.AddVersionedApiExplorer(o =>
{
    o.GroupNameFormat = "'v'VVV"; // v1, v2
    o.SubstituteApiVersionInUrl = true;
});

// Controller
using Asp.Versioning;

[ApiController]
[Route("api/v{version:apiVersion}/orders")]
public class OrdersController : ControllerBase
{
    [HttpGet]
    [ApiVersion("1.0", Deprecated = true)]
    public IActionResult GetV1() => Ok(new { message = "v1" });

    [HttpGet]
    [MapToApiVersion("2.0")]
    public IActionResult GetV2() => Ok(new { message = "v2", includes = new []{"items"} });
}

Schema Evolution Playbook (JSON & DTO)

Obey the following rules for compatibility‑safe evolution:

• Add‑only changes: Favor adding optional fields; do not remove/rename fields.
• Maintain defaults: When the new field is disregarded, the old functionality must not change.
• Enum extension: Clients should handle unknown enum values gracefully (default behavior).
• Deprecation pipeline: Mark fields/endpoints as deprecated at least one version prior to removal and publicize extensively. - Stability by contract: Record any unspoken contracts (ordering, casing, formats) that clients depend on.

Example: adding a non‑breaking field

public record OrderDto(
    Guid Id,
    decimal Total,
    string Currency,
    string? SalesChannel // new, optional
);

Compatibility‑Safe API Behaviors

• Error model: Use a standard structure (e.g., RFC 7807 ProblemDetails). Avoid ad‑hoc error shapes on a per-endpoint basis.
• Versioning/Deprecation communication through headers:
• api-supported-versions: 1.0, 2.0
• Deprecation: true (in deprecated endpoints)
• Sunset: Wed, 01 Oct 2025 00:00:00 GMT (planned deprecation date)
• Idempotency: Use an Idempotency-Key header for retry-safe POSTs.
• Optimistic concurrency: Utilize ETag/If-Match to prevent lost updates.
• Pagination: Prefer cursor tokens (nextPageToken) to protect clients from sorting/index changes.
• Time: Employ ISO‑8601 in UTC; record time‑zone semantics and rounding conventions.

Rollout & Deprecation Policy

A good deprecation policy is announce → coexist → remove:

1. Announce: Release changelog, docs, and comms (mail/Slack) with v2 information and the sunset date.
2. Coexist: Operate v1 and v2 side by side. Employ gateway percentage routing for progressive cutover.
3. Observability: Monitor errors/latency/usage by version. When v1 traffic falls below ~5%, plan for removal. 4) Remove: Post sunset date, return 410 (Gone) with a link to migration documentation.

Canary & Blue‑Green: Initialize v2 with a small traffic portion and compare error/latency budgets prior to scaling up.

Contract & Compatibility Testing

• Consumer‑Driven Contracts: Write expectations using Pact.NET; verify at provider CI.
• Golden files / snapshots: Freeze representative JSON payloads and automatically detect regressions.
• Version-specific smoke tests: Maintain separate, minimal test suites for v1 and v2.
• SemVer discipline: Minor = backward‑compatible; Major = breaking (avoid when possible).

Minimal example (xUnit + snapshot style):

[Fact]
public async Task Orders_v1_contract_should_match_snapshot()
{
    var resp = await _client.GetStringAsync("/api/v1/orders");
    Approvals.VerifyJson(resp); // snapshot comparison
}

Tooling & Docs (for .NET)

• Asp.Versioning (NuGet): API versioning + ApiExplorer integration.
• Swashbuckle / NSwag: Generate an OpenAPI definition for every version (/swagger/v1/swagger.json, /swagger/v2/swagger.json). Display both in Swagger UI.
• Polly: Client‑side retries/fallbacks to handle transient failures and ensure resilience.
• Serilog + OpenTelemetry: Collect metrics/logs/traces by version for observability and SLOs.

Swagger UI configuration by group name:

app.UseSwagger();
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "API v1");
c.SwaggerEndpoint("/swagger/v2/swagger.json", "API v2");
});

Conclusion

Backward compatibility is not a version number—it is disciplined change management. When you use add‑only schema evolution, a well‑defined versioning strategy, strict contract testing, and rolling rollout, you maintain microservice independence and safeguard consumer experience.

Introduction

We are going to compare here classical Webpack bundling, employed by Angular applications, with new Esbuild system. We are going to migrate step by step to new system.

What is the Webpack Build System?

It's a capable module bundler popular among web developers. It reduces a huge number of file formats, whether JavaScript, CSS, or even HTML, to a solitary output file. Angular long employed Webpack as its primary build system.

Why did Angular migrate away from Webpack? The reason are:

• Slow build times.
• Complex configuration.
• Increased build times as node_modules dependencies grow.

What is Esbuild?

Esbuild is a next-gen bundler that was specifically developed to bundle and compile JavaScript and TypeScript with incredible speed. It's developed with the programming language Go, and since it enjoys multi-core parallel processing, its speed is amplified tremendously.

Benchmark Tests: Esbuild vs Other Bundlers

JavaScript Benchmark

In this benchmark, we bundle the three.js library ten times without any cache to create a fresh bundle.

| Bundler | Time | Relative slowdown | Absolute speed | Output size | | ----------------- | ------ | ----------------- | -------------- | ----------- | | esbuild | 0.39s | 1x | 1403.7 kloc/s | 5.80mb | | parcel 2 | 14.91s | 38x | 36.7 kloc/s | 5.78mb | | rollup 4 + terser | 34.10s | 87x | 16.1 kloc/s | 5.82mb | | webpack 5 | 41.21s | 106x | 13.3 kloc/s | 5.84mb |

TypeScript Benchmark

This benchmark uses the Rome codebase to simulate bundling a large TypeScript project.

| Bundler | Time | Relative slowdown | Absolute speed | Output size | | --------- | ------ | ----------------- | -------------- | ----------- | | esbuild | 0.10s | 1x | 1318.4 kloc/s | 0.97mb | | parcel 2 | 6.91s | 69x | 16.1 kloc/s | 0.96mb | | webpack 5 | 16.69s | 167x | 8.3 kloc/s | 1.27mb |

Application Builder in Angular

Since Angular 17 and later, Angular's build system was rewritten to a large extent. The new build system uses the application builder, with options to help faster, quicker builds. The new builder:

• Offers simplified configuration files.
• Significantly reduces build times thanks to Esbuild.
• Integrates modern development needs such as SSR, prerendering, and HMR.
• Is enabled by default in new projects.

Migrating to the New Build System in Angular

Angular 17 and up comes with a new build system. You can migrate below versions of Angular with an automated tool. There's an automated schematics script from the Angular team to achieve that scenario.

Automated Migration (Recommended)

The automatic migration will remove Webpack-specific code and modify angular.json along with other relevant files.

ng update @angular/cli --name use-application-builder

Steps performed by migration:

• Builder conversion: Modifies existing old browser or application targets to new application builder.
• SSR Builders Removal: Deletes all existing SSR builders since the new application builder already includes SSR support.
• Configuration Updates: Update config files (angular.json) to be compatible with new system.
• Configuration Merge for TypeScript: Merges tsconfig.server.json and tsconfig.app.json with option to add option to add `"
• Updates to Server Code: Update server-side code (Node.js/Express) to correspond to new bootstrapping and directory structure.
• Strip Webpack-Specific Styles: Removes Webpack-specific syntax (^, ~) from style imports and reorganizes stylesheets.
• Dependency Optimisation: If -angular-devkit/build-angular or -angular-devkit/angular-common are not being used elsewhere, then it's substituted by a smaller and optim

Manual Migration

For existing Angular projects, manual migration to the new build system is available with two stable and supported options.

🔹 1. browser-esbuild Builder (Compatible Migration)

• Generates only the client-side bundle.
• Designed for compatibility with the old browser builder.
• Minimal breaking changes.

Example angular.json Modification:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser"

⬇️ Change to:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser-esbuild"

🔹 2. application Builder (Full Migration)

• Provides client-side and optional server-side rendering (SSR) support.
• Includes advanced features like build-time prerendering.
• Default builder for new Angular CLI projects.
• Recommended for future SSR implementations.

Example angular.json Modification:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser"

⬇️ Change to:

"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:application"

Additional Required Updates:

| Old Setting | New Setting / Explanation | | --------------------- | -------------------------------------- | | main | Rename to browser. | | polyfills | Should be an array, not a single file. | | buildOptimizer | Remove (handled by optimization). | | resourcesOutputPath | Remove (default is now media). | | vendorChunk | Remove (no longer needed). | | commonChunk | Remove (no longer needed). | | deployUrl | Remove (use <base href> instead). | | ngswConfigPath | Rename to serviceWorker. |

For SSR-Enabled Applications

• The original SSR builders were distinct (prerender, server, server-dev, app-shell) and are consolidated into one application
• ng update deletes old configurations and sets up a new @angular/ssr package.
• Server and code configurations are automatically adapted to a new system.
• It works with both application and browser-esbuild builders.

Conclusion

The new build system upgrade to Angular signifies an upgrade, bringing existing web development needs up to date by trading slow and cumbersome Webpack's infrastructure with succinctness and speed from Esbuild.

Introduction

Dependency Injection (DI) enables developers to build sustainable Angular applications. The inject function which arrived with Angular 14 enables developers to handle dependencies through a simpler and type-safe mechanism. This article presents our findings together with the advantages of this approach. The approach demonstrated in this article will benefit your Angular projects regardless.

Problem

The traditional method of dependency injection in Angular requires developers to specify dependencies through constructor methods. The method of dependency specification results in complex code that makes applications harder to understand and maintain as they expand. The development of extensive Angular applications with intricate components and multiple dependencies makes this issue more severe.

Solutions

The Angular team has developed a CLI schematics command that automatically migrates existing projects.

ng generate @angular/core:inject

Tradinational Dependency Injection

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html',
})
export class ExampleComponent {
  constructor(private exampleService: ExampleService) {}
}

This approach is familiar to most angular developers. If too many dependencies are injected with the constructor method and there are too many operations in the constructor method, it leads to complexity. Manageability and readability become difficult

The New Dependency Injection

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html',
})
export class ExampleComponent {
  private exampleService = inject(ExampleService);
}

It's a safer, cleaner, and easier-to-read replacement for the traditional constructor-based method that makes it easier for developers to keep their code better organized and consistent. By leveraging the inject function, you reduce boilerplate code, eliminate mistakes, and simplify testing. Your dependencies are simpler to maintain and manage, especially in larger applications where readability and maintainability are crucial to scale and introduce new team members effectively.

Why We Chose the inject Approach

The inject method have to became your choice for clean code because it made the code more readable and maintainable along with more developer-friendly. The method decreases boilerplate code and follows modern Angular development principles.

Implementation

You can use the automatic CLI schematic command for the migration or the following example demonstrates how to use manually inject in an Angular application.

Step 1: Import inject

import { Component, inject } from '@angular/core';
import { ExampleService } from './example.service';

@Component({
  selector: 'app-example',
  templateUrl: './example.component.html',
})
export class ExampleComponent {
  private exampleService = inject(ExampleService);

  exampleMethod() {
   this.exampleService.doSomething();
  }
}

Step 2: Using inject in Services

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

@Injectable({ providedIn: 'root' })
  export class ExampleService {
  private http = inject(HttpClient);

  doSomething() {
  return this.http.get('/api/example');
  }
}

Conclusion

The new inject function provided by Angular makes your code more maintainable through better dependency management. The inject approach benefits both standalone Angular applications by improving their architectural structure and developer productivity.

You can find additional information about Dependency Injection in Angular through their official documentation.