DEV Community: Abdullah D.

The Missing Link: Exposing APIs to AI Agents Without Writing Code

Abdullah D. — Sat, 27 Dec 2025 14:25:19 +0000

If you’ve started building AI agents using the Model Context Protocol (MCP), you’ve likely hit a specific wall: The Boilerplate Wall.

You have a robust (.NET) back-end API with domain logic, validation, and database access all neatly organized. You even have an OpenAPI (Swagger) specification that describes exactly what the API does.

Yet, to make this accessible to an LLM (like Claude or a local Llama instance), developers often find themselves manually writing "Tool Definitions"—basically re-typing the API schema into a format the AI understands.

MCPify was created to tear down that wall.

The Problem: Two Sources of Truth

In the current ecosystem, allowing an AI to interact with a system usually requires:

Defining a Tool (Name, Description, Input Schema).
Mapping that tool to a C# method.
Keeping that mapping updated every time the API changes.

If a query parameter is added to a controller but the MCP tool definition isn't updated, the AI starts hallucinating arguments or failing silently.

The Solution: Swagger Is The Tool Definition

Since the API already describes itself via OpenAPI/Swagger, that should be treated as the single source of truth.

MCPify is a library for .NET 8+ that acts as a dynamic bridge. It reads the OpenAPI specification (v2, v3, or v3.1) at runtime and projects it into the MCP Tool format automatically.

How It Works

Instead of hard-coding tools, MCPify injects itself into the Dependency Injection container. It parses the Swagger JSON, resolves the schemas, and automatically hosts the required MCP endpoints (SSE/Stdio).

Getting Started in 3 Steps

It is designed to be "install and forget."

1. Installation

Add the package to the ASP.NET Core project:

dotnet add package MCPify

2. Configuration

In Program.cs, register the service. Provide the URL of the Swagger spec and the Base URL where the API requests should be sent.

using MCPify.Hosting;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddMcpify(
    swaggerUrl: "https://localhost:5001/swagger/v1/swagger.json",
    apiBaseUrl: "https://localhost:5001",
    options => 
    {
        // Optional: Add a prefix to all tools to avoid naming collisions
        options.ToolPrefix = "myapi_";

        // Optional: Filter specific endpoints
        // options.Filter = op => op.Route.Contains("/products");
    }
);

3. Usage

No custom MCP server implementation is required. Just map the endpoint, and MCPify handles the protocol communication (SSE/Post).

var app = builder.Build();

// Automatically creates the /sse and /messages endpoints
app.MapMcpifyEndpoint();

app.Run();

Once running, connect the MCP client (like Claude Desktop) to:
http://localhost:<YOUR_PORT>/sse

> **Note:* Ensure you replace <YOUR_PORT> (e.g., 5000, 5005, 5132, ...) with the actual port number your application is listening on.*

Why This Matters

Rapid Prototyping: Spin up an agent that controls an entire backend in minutes, not days.
Maintenance Free: If a field is renamed in a DTO, the AI agent knows about the change as soon as the Swagger updates.
Ecosystem Compatibility: It handles the complex work of converting OpenAPI JSON schemas into the specific format MCP expects.

What's Next?

Future updates aim to add support for authentication bridging (passing user tokens through to the tools) and more granular control over operation filtering.

Developers building Agentic AI with .NET are encouraged to try it out.

GitHub: github.com/abdebek/MCPify
NuGet: nuget.org/packages/MCPify

Stop Overwrites with One Attribute: EF Core DbConcurrency Made Simple

Abdullah D. — Wed, 17 Sep 2025 13:18:54 +0000

The Silent Data Loss Problem Every Multi-User App Faces

Multi-user applications have a dangerous default behavior that many developers don't realize until it's too late. When multiple users modify the same data simultaneously, the last person to save wins, and everyone else's changes disappear without a trace.

Silent data loss. No exceptions thrown, no error messages, no warnings - just data quietly vanishing.

The good news? EF Core has a built-in solution that requires just one attribute.

The Problem: When "Last Write Wins" Becomes "Everyone Loses"

In multi-user applications, the default behavior is deceptively dangerous. When multiple users modify the same entity simultaneously, the last person to save wins, and everyone else's changes disappear without a trace.

Here's how this common scenario unfolds:

User A loads a product (Stock: 100, Price: $25.99, Name: "Widget")
User B loads the same product (Stock: 100, Price: $25.99, Name: "Widget")
User A changes the stock to 1000 (maybe bulk inventory adjustment)
User B reduces stock to 75 via raw SQL (direct database update)
User A saves their changes ✅
Result: User A's stock value (1000) overwrites User B's stock change (75) 💥

The key insight: Data loss occurs when both users modify the same field concurrently. If User A only changed the name and price (leaving stock untouched), User B's stock change would survive. But when both operations touch the same field, the EF Core save overwrites the direct database change.

Note: This happens specifically when EF Core's SaveChanges() includes a field that was also modified by raw SQL or another concurrent operation.

The Hero: One Attribute to Rule Them All

Meet the [Timestamp] attribute - EF Core's built-in superhero for data integrity:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Stock { get; set; }
    public decimal Price { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; } = new byte[8];  // 🦸‍♂️ Your data guardian
}

That's it. One attribute. Eight bytes. Zero data loss.

The Magic Behind the Scenes

When you add [Timestamp] to a property, EF Core transforms from a passive bystander into an active protector:

Without RowVersion (The Dangerous Way):

-- User B's save overwrites everything
UPDATE Products 
SET Name = 'Original Widget', Stock = 50, Price = 25.99 
WHERE Id = 1

With RowVersion (The Safe Way):

-- EF Core includes the version in the WHERE clause
UPDATE Products 
SET Name = 'Premium Widget', Stock = 50, Price = 29.99 
WHERE Id = 1 AND RowVersion = 0x00000000000007D0

If another user changed the data (updating the RowVersion), this query affects 0 rows, triggering a DbUpdateConcurrencyException. No silent data loss. Ever.

See It In Action: The Demo That Will Change How You Think About Data

I built a working demo that shows exactly what happens with and without concurrency control. Here's what you can test:

🔴 The Dangerous Scenario

POST /demo-concurrency-with-stock-change

What happens: EF Core silently overwrites concurrent changes. Data loss occurs, and nobody knows.

🟢 The Protected Scenario

POST /demo-with-rowversion

What happens: DbUpdateConcurrencyException is thrown. The conflict is detected and must be handled explicitly.

🟡 The Edge Case

POST /demo-concurrency-no-stock-change

What happens: When EF Core doesn't modify a field, concurrent raw SQL changes survive. Interesting, but not reliable for production.

Handling Conflicts Like a Pro

When DbUpdateConcurrencyException occurs, you have three battle-tested strategies:

1. Store Wins (Reload and Show Current Data)

catch (DbUpdateConcurrencyException)
{
    await context.Entry(product).ReloadAsync();
    // Show user the current database values
    // Let them decide what to do
}

2. Client Wins (Force the Update)

catch (DbUpdateConcurrencyException ex)
{
    var entry = ex.Entries.Single();
    entry.OriginalValues.SetValues(entry.GetDatabaseValues());
    await context.SaveChangesAsync(); // Force save
}

3. Smart Merge (Best of Both Worlds)

catch (DbUpdateConcurrencyException ex)
{
    var entry = ex.Entries.Single();
    var currentValues = entry.CurrentValues;
    var databaseValues = entry.GetDatabaseValues();

    // Example: Keep user's name/price changes, preserve database stock
    currentValues["Stock"] = databaseValues["Stock"];

    entry.OriginalValues.SetValues(databaseValues);
    await context.SaveChangesAsync();
}

The Business Case: Why This Matters

The Cost of Data Loss:

E-commerce: Incorrect inventory leads to overselling
Finance: Transaction amounts get corrupted
Healthcare: Patient data becomes inconsistent
Any Business: User trust erodes, reputation suffers

The Cost of Implementation:

Development Time: 5 minutes to add the attribute
Performance Impact: ~1ms per operation
Storage Cost: 8 bytes per row
Maintenance: Zero - it just works

ROI: Infinite. You can't put a price on data integrity.

The Developer's Concurrency Checklist

✅ Always Use RowVersion For:

Multi-user applications
Financial transactions
Inventory management
Any critical business data
Long-running forms

📋 Implementation Best Practices:

Create a Base Entity:

public abstract class BaseEntity
{
    public int Id { get; set; }

    [Timestamp]
    public byte[] RowVersion { get; set; } = new byte[8];
}

// Now all your entities are protected
public class Product : BaseEntity
{
    public string Name { get; set; } = "";
    public int Stock { get; set; }
    public decimal Price { get; set; }
}

Test Concurrent Scenarios:

[Fact]
public async Task Should_Detect_Concurrent_Updates()
{
    // Load same entity in two contexts
    var product1 = await context1.Products.FindAsync(id);
    var product2 = await context2.Products.FindAsync(id);

    // Modify both
    product1.Name = "Version 1";
    product2.Stock = 50;

    // First save succeeds
    await context1.SaveChangesAsync();

    // Second save should throw
    await Assert.ThrowsAsync<DbUpdateConcurrencyException>(
        () => context2.SaveChangesAsync());
}

The Reality Check: Performance vs. Protection

Aspect	Without RowVersion	With RowVersion
Data Loss Risk	❌ High	✅ None
Conflict Detection	❌ Silent failure	✅ Explicit exception
Implementation Effort	None	1 attribute
Performance Impact	Baseline	+8 bytes, +~1ms
Peace of Mind	❌ Sleepless nights	✅ Sleep like a baby

Try It Yourself

The complete demo is available on GitHub. Clone it, run it, and see the magic happen:

git clone https://github.com/abdebek/efcore-db-concurrency-demo.git
cd efcore-db-concurrency-demo
dotnet restore
dotnet run

# Test the scenarios
curl -X POST https://localhost:7112/demo-with-rowversion

The Bottom Line

In a world where data is your most valuable asset, can you afford NOT to protect it?

The [Timestamp] attribute is:

✅ Built into EF Core
✅ Automatic and reliable
✅ Zero maintenance
✅ Battle-tested in production
✅ The difference between data loss and data safety

One attribute. Zero data loss. That's the power of [Timestamp].

Have you experienced silent data loss in your applications? How did you solve it? Share your story in the comments below!

🔗 Useful Resources:

👏 Found this helpful? Give it a clap and follow for more practical development insights!

Secure Your .NET 8 APIs in Minutes with OpenIddict: A Minimalist's Guide

Abdullah D. — Sun, 31 Aug 2025 18:01:37 +0000

API security is non-negotiable, but implementing OAuth 2.0 and OpenID Connect can often feel like a monumental task, bogged down by complex configurations and boilerplate code. What if you could set up a robust, spec-compliant OIDC server for your .NET API in just a few minutes, with code that fits on a single screen?

That's exactly what I set out to do. I've created a minimal, self-contained OpenIddict server that provides a rock-solid foundation for token-based authentication, and I've published the complete source code on GitHub.

This guide will walk you through how it works and how you can get it running in less time than it takes to brew your morning coffee.

You can find the full, ready-to-run project here.

Why OpenIddict? The Power of "No Magic"

There are many identity solutions for .NET, but OpenIddict stands out for its "no magic" philosophy. It's a low-level, highly configurable framework that gives you full control over the authentication flow. Instead of hiding the implementation behind layers of abstraction, it provides the essential building blocks, allowing you to build a server that is both powerful and transparent.

This project embraces that philosophy to create an API-first server with key features:

OIDC & OAuth 2.0 Compliant: No shortcuts, just standard-based security.
Essential Flows Included: Supports Password, Client Credentials, and Refresh Token grants out-of-the-box.
Minimal & Self-Contained: The entire configuration is in Program.cs. No hunting through files to understand what's going on.
Instant Testing: Comes with a pre-seeded client and admin user.

The Core Configuration: Less Code, More Security

The heart of the server is in the Program.cs file. By chaining a few configuration methods, we can set up the entire OpenID Connect server.

Here's a look at the core AddOpenIddict() configuration:

builder.Services.AddOpenIddict()
    .AddCore(/*...EF Core setup...*/)
    .AddServer(options =>
    {
        // 1. Set the endpoint URIs
        options.SetTokenEndpointUris("connect/token")
               .SetUserinfoEndpointUris("connect/userinfo");

        // 2. Enable the grant types you need
        options.AllowPasswordFlow()
               .AllowRefreshTokenFlow()
               .AllowClientCredentialsFlow();

        // 3. Explicitly enable the endpoints
        options.AllowUserinfoEndpoint()
               .AllowIntrospectionEndpoint()
               .AllowRevocationEndpoint();

        // 4. Configure certificates and ASP.NET Core integration
        options.AddDevelopmentEncryptionCertificate()
               .AddDevelopmentSigningCertificate();

        options.UseAspNetCore()
               .EnableTokenEndpointPassthrough();
    })
    .AddValidation(/*...JWT validation setup...*/);

In this small block of code, we've configured our endpoints, enabled specific OAuth 2.0 flows, registered scopes, and set up our development certificates. It's clean, readable, and incredibly efficient.

Get it Running in Under a Minute

Getting the server running on your machine is a simple two-step process.

Restore Dependencies:

   dotnet restore

Run the Server:

   dotnet run

That's it! The first time you run it, an openiddict.db SQLite file is created, and the database is automatically seeded with a test client (postman) and an admin user (admin@test.com). No manual database setup required.

Testing Your Secure Endpoints

To make testing easy, the project includes an api.http file. If you use Visual Studio Code with the REST Client extension, you can immediately start sending requests.

Here's how you would request a token using the password flow:

# From api.http

POST http://localhost:5000/connect/token
Content-Type: application/x-www-form-urlencoded

grant_type=password
&client_id=postman
&client_secret=postman-secret
&username=admin@test.com
&password=AdminPassword123!
&scope=openid profile api

Just click "Send Request," and you'll get back a live access token and refresh token.

Conclusion: Your Foundation for Secure APIs

This minimal server is the perfect starting point. It solves the immediate, and often complex, problem of setting up a secure token service. From here, you can easily extend it to support more flows, integrate it with a frontend application, or deploy it as a central authentication authority for your microservices.

Building secure APIs doesn't have to be a headache. With the right tools and a clean, minimal approach, you can create a robust and transparent authentication system.

Check out the repository on GitHub, clone the code, and see for yourself!

Building True Micro-Frontends: Beyond iFrames with Module Federation

Abdullah D. — Sat, 16 Aug 2025 05:56:12 +0000

The Evolution of Frontend Architecture

In today's fast-paced development landscape, monolithic frontend applications often become bottlenecks for large teams. Enter micro-frontends – an architectural pattern that brings the benefits of microservices to the frontend world. But not all micro-frontend implementations are created equal.

What Makes a "True" Micro-Frontend?

Many developers think micro-frontends are just multiple applications running in iframes. While this approach works, it comes with significant limitations:

Poor User Experience: Scrolling issues, navigation problems, and inconsistent styling
Limited Communication: Complex postMessage APIs for inter-app communication
SEO Challenges: Search engines struggle with iframe-based content
Performance Issues: Each iframe loads its own resources independently

Enter Module Federation: The Game Changer

Webpack Module Federation revolutionizes how we build micro-frontends by enabling true runtime integration. Unlike iframe-based solutions, Module Federation allows applications to dynamically load and share code at runtime, creating a seamless user experience.

Key Benefits of Module Federation

🔄 Runtime Code Sharing: Applications can share dependencies like React, reducing bundle sizes and improving performance.

🚀 Independent Deployment: Teams can deploy their micro-frontends independently without affecting others.

🛠️ Technology Diversity: Different teams can use different tech stacks while maintaining integration.

🎯 Seamless Integration: No iframe boundaries means natural scrolling, navigation, and styling.

Real-World Architecture in Action

Let's explore a practical implementation that demonstrates these concepts:

┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Shell App       │ │ Landing MFE     │ │ Dashboard MFE   │
│ (Port 3000)     │◄──►│ (Port 3001)     │ │ (Port 3002)     │
│                 │ │                 │ │                 │
│ • Navigation    │ │ • Marketing     │ │ • Analytics     │
│ • Routing       │ │ • Features      │ │ • Charts        │
│ • Error Bounds  │ │ • Onboarding    │ │ • Real-time     │
└─────────────────┘ └─────────────────┘ └─────────────────┘

The Shell Application: Your Orchestra Conductor

The shell app acts as the main orchestrator, handling:

Global Navigation: Consistent header and routing across micro-frontends
Error Boundaries: Graceful failure handling when micro-frontends fail to load
Authentication: Shared user state across all applications
Theme Management: Consistent styling and branding

Micro-Frontend Components: Independent Yet Connected

Each micro-frontend operates independently but integrates seamlessly:

Landing Micro-Frontend:

Marketing content and feature highlights
User onboarding flows
Standalone operation for marketing campaigns

Dashboard Micro-Frontend:

Real-time analytics and data visualization
Interactive charts and reports
Independent development and testing cycles

Configuration Made Simple

Setting up Module Federation with Vite is surprisingly straightforward:

Shell Configuration

// vite.config.ts (Shell App)
federation({
  name: 'shell',
  remotes: {
    landing: 'http://localhost:3001/assets/remoteEntry.js',
    dashboard: 'http://localhost:3002/assets/remoteEntry.js'
  },
  shared: ['react', 'react-dom']
})

Micro-Frontend Configuration

// vite.config.ts (Landing MFE)
federation({
  name: 'landing',
  filename: 'remoteEntry.js',
  exposes: {
    './App': './src/App'
  },
  shared: ['react', 'react-dom']
})

Development Experience That Doesn't Compromise

One of Module Federation's strongest advantages is maintaining an excellent developer experience:

Hot Reloading: Works seamlessly across all micro-frontends
Debugging: Standard browser dev tools work without iframe complications
TypeScript Support: Full type safety across micro-frontend boundaries
Independent Development: Teams can work in isolation while testing integration

Production-Ready Architecture

This isn't just a proof-of-concept – companies like Spotify, ByteDance, and Microsoft use Module Federation in production. The architecture provides:

Scalability Benefits

Team Autonomy: Different teams can own different parts of the application
Technology Flexibility: Mix React, Vue, Angular, or vanilla JavaScript as needed
Deployment Independence: Deploy updates without coordinating with other teams
Failure Isolation: One micro-frontend's issues don't crash the entire application

Performance Optimizations

Shared Dependencies: React loaded once, used everywhere
Lazy Loading: Micro-frontends load on-demand
Caching Strategies: Individual micro-frontends can be cached independently
Bundle Optimization: Only load what's needed when it's needed

When to Choose Module Federation

This architecture shines in several scenarios:

Large Organizations: Multiple teams working on different features need coordination without tight coupling.

Legacy Migration: Gradually modernize monolithic applications by extracting features into micro-frontends.

Multi-Brand Products: Different user interfaces sharing common functionality and backend services.

Rapid Scaling: Independent development and deployment cycles accelerate feature delivery.

Getting Started: A Practical Roadmap

Phase 1: Foundation

Set up your shell application with basic routing
Create your first micro-frontend with a simple component
Configure Module Federation between them
Implement error boundaries for graceful failures

Phase 2: Enhancement

Add shared state management across micro-frontends
Implement authentication and authorization patterns
Set up consistent styling and theming
Add comprehensive error handling and monitoring

Phase 3: Production

Configure CI/CD pipelines for independent deployment
Set up monitoring and performance tracking
Implement E2E testing strategies
Document integration patterns for your team

The Technology Stack

A modern implementation typically includes:

React 18 with TypeScript for type safety
Vite with Module Federation plugin for fast builds
Tailwind CSS for consistent, utility-first styling
React Router for seamless navigation
Error Boundaries for graceful failure handling

Beyond the Basics: Advanced Patterns

Shared Component Libraries

Create a design system that all micro-frontends can consume, ensuring visual consistency while maintaining independence.

Event-Driven Communication

Implement pub/sub patterns for loose coupling between micro-frontends, allowing them to communicate without direct dependencies.

Progressive Loading

Load micro-frontends progressively based on user interaction, optimizing initial page load times.

Conclusion: The Future is Modular

Module Federation represents a significant leap forward in frontend architecture. It provides the benefits of micro-frontends – team autonomy, independent deployment, technology diversity – without the drawbacks of iframe-based solutions.

As applications grow in complexity and teams scale, the ability to develop, deploy, and maintain features independently becomes crucial. Module Federation makes this possible while maintaining the seamless user experience that modern web applications demand.

The architecture isn't just about technology; it's about enabling teams to work efficiently at scale. By embracing true micro-frontend patterns, organizations can accelerate development, improve maintainability, and create better experiences for both developers and users.

Ready to explore this architecture hands-on? Check out the complete implementation that demonstrates these concepts in a production-ready setup. The future of frontend development is modular, independent, and surprisingly elegant.

Want to dive deeper into micro-frontend architecture? The implementation referenced in this article provides a complete, runnable example with TypeScript, modern tooling, and production-ready patterns you can use as a foundation for your own projects.

Is Your Code Easy to Read and Maintain? A Deep Dive into Cyclomatic Complexity

Abdullah D. — Thu, 24 Jul 2025 07:26:18 +0000

Ever stared down a function with a Cyclomatic Complexity (CC) score over 50? You're not alone. That metric isn't just an abstract number; it's a flashing warning sign for a sprawling, untestable, and bug-ridden monster lurking in your codebase.

What Is Cyclomatic Complexity (CC)?

At its core, Cyclomatic Complexity is a software metric that quantifies the structural complexity of a program.

Think of your code as a map: CC tells you the number of independent paths (or unique routes) a user's execution could take from start to finish. Essentially, it measures how many different decisions your code makes. The more decisions, the higher the complexity, and the harder the code is to understand and test.

The Complexity Scorecard

These are the generally accepted guidelines for interpreting a CC score:

CC Range	Interpretation	Impact & Action
1–10	Excellent 🟢	Simple, clear, and highly testable. Keep it this way!
11–20	Moderate 🟡	Manageable, but start being mindful. Consider minor refactoring.
21–50	High 🟠	Difficult to read, test, and maintain. Needs immediate refactoring to break it into smaller functions.
> 50	Danger Zone 🔴	A clear sign of deeply entangled, spaghetti logic. This is an urgent refactoring priority before new bugs appear.

What Makes CC Skyrocket?

CC increases every time your code introduces a new point of decision or control flow.

The following structures are the primary contributors:

Conditional Statements: Each if/else branch adds a path.
Loops: for, while, and do-while constructs introduce branching.
Case Statements: Every case within a switch block is a separate path.
Logical Operators: Using logical AND (&&) and OR (||) within a condition effectively adds to the complexity count because they represent multiple conditions that must be checked.
Ternary Operators: The compact ? : operator still adds a decision path.

The True Cost of High Complexity 📉

Why should you, as a developer or a team lead, obsess over this number? Because high complexity directly impacts your team's productivity and sanity:

Debugging Hell: More paths mean an exponential increase in places for bugs to hide. Tracing execution through tangled logic can turn a 10-minute fix into an all-day ordeal.
Testing Nightmare: Achieving full code coverage becomes nearly impossible. You'd need to write an unmanageable number of unit tests just to cover every possible flow, and even then, subtle interactions can be missed.
Maintenance Dread: Understanding and safely modifying the code becomes a Herculean task. Developers are hesitant to touch complex modules, leading to technical debt and slower feature development.

Your First Line of Defense: Static Analysis Tools 🛡️

The best way to fight complexity is to catch it early. Don't wait until you're debugging a CC > 50 function at 2 AM.

Modern static analysis tools are game-changers:

Automated Flagging: Tools like CodeMetrics (available as extensions for VS Code, Visual Studio, IntelliJ, etc.) proactively calculate CC as you code.
Early Intervention: They immediately flag complex code, enabling you to refactor before it spirals out of control.
Team Standards: They help enforce a consistent complexity limit across your entire team.

Pro Tip: Set a firm, automated rule on your CI/CD pipeline to fail a build if the CC of any new or modified function exceeds a threshold, like 20. This forces quality up-front.

Don't let complexity turn your codebase into a nightmare. Embrace static analysis tools, prioritize breaking large functions into smaller, single-responsibility units, and make refactoring for lower complexity a core part of your development process! Cleaner code is faster code.