DEV Community: Christian Alt-Wibbing

Minimal APIs, Controllers & FastEndpoints Compared

Christian Alt-Wibbing — Wed, 22 Apr 2026 06:25:36 +0000

What is this about?

When you build a new API in .NET 10 today, you face a decision that didn’t exist before: Minimal API, classic Controllers, or FastEndpoints? All three are fully capable approaches — but they have different strengths, weaknesses, and use cases.
In this post, we take an honest look at all three.

Minimal APIs — lean, modern, fast

Minimal APIs were introduced with .NET 6 and have evolved significantly since then. In .NET 10, they have truly come of age.

The simplest endpoint in the world

app.MapGet("/ping", () => "pong");

That’s a complete API. One line. No controller, no class, no attribute.

What’s new in .NET 10?

Built-in Validation Previously you had to either pull in FluentValidation or write your own checks. Now a simple call is enough:

builder.Services.AddValidation();

Your DTO with DataAnnotations is then automatically validated — and on failure, a clean ProblemDetails response is returned. No more manual if-statement juggling.

Endpoint Filters instead of Action Filters

Instead of Action Filters, Minimal APIs use Endpoint Filters. The concept is similar — logic before or after the handler — but less powerful:

app.MapPost("/orders", Handler)
     .AddEndpointFilter<LoggingFilter>()
     .AddEndpointFilter<ValidationFilter>();

Filters run from outside in — like middleware onions. For logging, validation, and simple auth checks, this works well. For complex result manipulation, it gets tricky.

The biggest advantage in my opinion: Native AOT

Minimal APIs support Native AOT (Ahead-of-Time Compilation) — Controllers do not. That means: no JIT at runtime, lightning-fast startup, less memory, smaller deployments. A real game-changer for Lambda functions, Kubernetes pods, or edge deployments.

Extracting endpoints — the Extension Method trick

A clean solution for larger projects: move endpoints into their own > classes and register them via Extension Methods:
public static class OrderEndpoints {     
  public static WebApplication MapOrderEndpoints(this WebApplication >app){
     app.MapPost("/orders", HandleCreate);         
     app.MapGet("/orders/{id}", HandleGet);         
     return app;     
  } 
}
Program.cs stays clean:
app.MapOrderEndpoints(); 
app.MapProductEndpoints(); 
app.MapCustomerEndpoints();

Controllers — proven, structured, complete

Controllers are the classic approach in ASP.NET Core. They’ve been around for years, are well documented, and every .NET developer knows them.

What Controllers do better

Action Filter Pipeline — this is the biggest difference. Controllers have

OnActionExecuting,
OnActionExecuted,
OnResultExecuting

very fine-grained control over different phases of the request lifecycle.

Direct Unit Testability — you can instantiate a controller directly and test it without spinning up the entire HTTP stack:
var controller = new OrdersController(mockService); var result = controller.Create(request);

Proven Structure — one class per resource, methods per action. New team member? They’ll find their way around immediately.

What Controllers cannot do

No Native AOT support — Controllers rely too heavily on Reflection, and Reflection is incompatible with Native AOT. This is a fundamental limitation, not a bug.

FastEndpoints — the best of both worlds

FastEndpoints is an open-source library that builds on top of Minimal APIs — but gives you a clean, structured development experience on top.

The REPR Pattern

The core concept is the REPR Pattern — Request → Endpoint → Response. Each endpoint gets its own class. Not one controller class with 10 methods — but truly one class per endpoint:

public class CreateOrderEndpoint : Endpoint<CreateOrderRequest> 
{     
   public override void Configure(){
         Post("/orders");
         AllowAnonymous();     
   }      
   public override async Task HandleAsync(CreateOrderRequest req,
                                          CancellationToken ct)
   {
         await SendOkAsync("Order created");     
   }
}

You can see: it has the structure of Controllers — a class, clear methods — but the performance of Minimal APIs underneath.
What FastEndpoints brings
• Built-in Validation with FluentValidation — directly integrated
• Filter System — similar to Action Filters, cleanly implemented
• Performance on par with Minimal APIs — noticeably faster than Controllers
• Native AOT Support — because it builds on Minimal APIs

The trade-off

FastEndpoints is an external dependency. You’re bringing in a library with its own concepts. New team members need to learn it. The community is smaller than for Controllers or Minimal APIs.

Conclusion — which one should I pick?

The honest answer: it depends. But here’s a simple rule of thumb:
• Minimal API → Small, fast, modern. Perfect for microservices and cloud-native.
• Controllers → Large, proven, structured. Perfect for large teams and complex projects.
• FastEndpoints → The best of both worlds — with an external dependency as the price.

And the great thing: all three can coexist in the same app. You can start with Minimal APIs and migrate to FastEndpoints later — or keep Controllers for complex parts and use Minimal APIs for simple endpoints.

For further information you can read following Sources

Vibe Coding – The Revolution of Software Development or Just a Hype

Christian Alt-Wibbing — Fri, 09 May 2025 13:00:39 +0000

In the fast-paced world of software development, new buzzwords and trends are constantly emerging. One of the hottest current topics is something called Vibe Coding. But what’s behind this term that’s dividing opinions—praised by some as revolutionary, dismissed by others as “total garbage”?

What is Vibe Coding, really?

The term Vibe Coding was coined in February 2025 by computer scientist Andrej Karpathy, co-founder of OpenAI and former AI lead at Tesla. He described it as a conversation-based approach where spoken commands are used while an Artificial Intelligence (AI) generates the actual code. Karpathy himself said:

It's not really coding - I just see things, say things, run things, and copy-paste things, and it mostly works.

At its core, Vibe Coding describes a programming technique that relies entirely on AI to write source code, making programming accessible even to those without experience. Instead of manually coding, the user describes a problem in a few sentences as a prompt for a large language model (LLM) with sufficient programming knowledge. The LLM then generates the software, shifting the programmer’s role from writing code to guiding, testing, and refining the AI-generated output.

From Hobby Projects to Startup Codebases

Vibe Coding allows even inexperienced users to create software prototypes without deep training or technical skills. It's gaining traction for its ability to rapidly turn ideas into prototypes with minimal technical effort.

However, experts warn that the results are often limited and error-prone. In one case, AI-generated code produced fake reviews for an e-commerce site. Roose suggested that Vibe Coding is better suited to hobby projects than to mission-critical tasks.

The Potential of Vibe Coding

Faster from idea to prototype: Vibe Coding can significantly lower the barrier between an idea and working software. People without coding experience can bring their visions to life quickly.
Focus on the idea: Instead of getting lost in technical details, users can focus on the functionality and user experience of the application.
Increased efficiency: Even professional developers can use Vibe Coding to generate boilerplate code or quickly build first versions of software.
Learning effect: Interacting with AI-generated code can give non-technical users a basic understanding of software development.

Challenges and Criticism

Despite the potential benefits, there are major concerns and criticisms around Vibe Coding:

Understanding: Developers might use AI-generated code without fully understanding how it works, leading to undetected bugs, malfunctions, or security flaws.
Quality and maintainability: LLMs often produce code without considering architecture, reusability, or maintainability. The result can be unclear and inconsistent code.
Security risks: Blind trust in AI-generated code can lead to security vulnerabilities, like accidentally leaking API keys.
Loss of coding skills: Overreliance on AI may result in a loss of programming proficiency and dependency on AI tools.
Accountability: It's often unclear who is responsible for errors or security issues in AI-generated code.

Some voices in the developer community are highly critical of Vibe Coding. In one Reddit thread, it was labeled “total garbage.” Others expressed concerns over the loss of learning processes and the neglect of security practices.

Tools Supporting Vibe Coding

Despite criticism, a growing number of tools and platforms are making Vibe Coding more accessible:

IDEs with AI integration: Tools like Cursor enable direct interaction with AI models for code generation.
VS Code extensions: The Cline plugin brings AI features into the popular VS Code editor.
Online code editors: Replit offers a web-based IDE with built-in AI agents capable of generating full applications from natural language prompts.
AI assistants with canvas features: Platforms like Claude, ChatGPT, and Google AI let users write and run code directly in the browser.
Dedicated Vibe Coding platforms: Replit also offers easy deployment and integrated cloud services for quick project launches.

Conclusion: More than just a Vibe?

Vibe Coding is trending—and it could significantly change the way we develop software. It enables faster development and lowers the barrier for those without much experience.

But: blindly trusting code written by AI can be risky. It might have errors, be insecure, or hard to understand.

Most likely, the future will be a mix of traditional programming and AI-assisted tools. Vibe Coding is great for quick tests, small apps, or automating boring tasks. For critical or complex projects, however, a deep understanding of the code and thorough review is still essential.

Whether Vibe Coding turns out to be more than just a short-lived trend remains to be seen.

What matters most is to stay open to innovation—but also to approach it carefully and thoughtfully.

Software Development: Art, Science, and Gardening

Christian Alt-Wibbing — Fri, 09 May 2025 12:37:14 +0000

"Is software developed or cultivated?" This question brings an intriguing perspective to the world of software development. When we write software, do we follow strict methods, or is it a creative, artistic process? And what does it mean to treat a software system like a garden?

Art and Science: Two Perspectives on Software Development

In the debate over whether software development is an art or a science, it quickly becomes clear how much our perspective shapes our thinking and approach. When we see software development as a science, we emphasize structured, reproducible processes and precise results created through clear rules. In science, we often seek the best, reproducible solution, based on data and analysis. In software development, this might mean relying on design patterns, algorithms, and a strict adherence to best practices that streamline the development process.

On the other hand, there’s the artistic approach: Here, it’s less about following rules and more about creativity, expression, and problem-solving from various, often innovative perspectives. Just as artists shape a blank canvas, developers bring their ideas to life through code, exploring new paths and making choices that go beyond mere functionality. Solutions may be elegant and unique, but they often reflect personal preferences, leading to different styles and approaches.

A Living Organism: Understanding Software as a Garden

In his book Code That Fits in Your Head, Mark Seemann offers an intriguing alternative: Instead of seeing software solely as art or science, we might think of it as a living organism or a garden. A garden isn’t static – it grows, changes, and without regular care, it can become overgrown.

For software, this means that without regular refactoring and removal of obsolete elements, a codebase gradually loses structure and clarity. An overgrown garden is difficult to manage and ultimately costs more time and effort. By viewing software development as continuous maintenance, we work proactively to keep the system stable and sustainable – striking a balance between the precision of science and the creativity of art. But just like any garden, this raises the question of how much maintenance is enough, and when does it become too much? Even an overly groomed garden can look crowded and chaotic.

Looking to the Past: The Journeyman's Years as a Model for Learning Developers

An inspiring idea is to revisit the European tradition of the journeyman's years, also known as the “Wanderjahre” or “Walz” in germany. In the past, craftsmen would travel from town to town, learning from different masters and gaining valuable experience that shaped their skills and style. Applied to software development, this approach could mean that developers benefit from working on diverse projects, with various mentors and teams, to learn new ideas and techniques. This approach preserves flexibility and fosters a broad understanding of different problem-solving methods.

The Risk of Overengineering

"The brighter the light, the darker the shadow."

When efforts to make software “perfect” go too far, extra abstractions and complexity can unnecessarily bloat the system. As knowledge and skills grow, so too does the risk of overengineering. The more tools and techniques a developer masters, the greater the temptation to craft solutions that are more complex and intricate than necessary. This drive to make everything perfect and "elegant" can make the code unnecessarily complicated and hard to maintain. A well-maintained “garden” is only as complex as needed and as simple as possible.

Conclusion: Striking a Balance between Structure and Creativity

Ultimately, the art of software development lies in balancing these different approaches. Guidelines and best practices create a framework that elevates software development to engineering, while still leaving room for the creative freedom that enables innovative and elegant solutions. A sustainably maintained "software garden" relies on retaining an overview, eliminating outdated structures, finding the right balance between creativity and discipline, and occasionally switching teams or projects.

How do you maintain your code? Do you strictly adhere to scientific methods, or do you see your work as artistic expression? Share your views and experiences in the comments – how do you keep your codebase maintainable and elegant?