Fix 6.1 blog: correct OllamaSharp vs Microsoft.Extensions.AI narrative

Author: workcontrolgit

blogs/series-6-ai-app-features/6.1-dotnet-ai-foundation.md

@@ -1,10 +1,10 @@
 # Run a Local LLM in Your .NET 10 API with Ollama
 
-## How Microsoft.Extensions.AI Makes Your API AI-Ready Without Locking You Into One Provider
+## How OllamaSharp and a Custom Service Interface Make Your .NET 10 API AI-Ready
 
 Every developer wants AI in their app. The problem is getting started: API keys, cloud costs, rate limits, and the fear of betting your architecture on one vendor. What if you could add a working AI endpoint to your .NET 10 API in under an hour — for free, running entirely on your laptop?
 
-This article shows you exactly how, using [Ollama](https://ollama.com) for a local LLM and `Microsoft.Extensions.AI` as a provider-agnostic abstraction.
+This article shows you exactly how, using [Ollama](https://ollama.com) for a local LLM and [OllamaSharp](https://github.com/awaescher/OllamaSharp) as the .NET client library.
 
 📖 **Tutorial Repository:** [AngularNetTutorial on GitHub](https://github.com/workcontrolgit/AngularNetTutorial)
 
@@ -16,11 +16,11 @@ This article is part of the **AngularNetTutorial** series. The full-stack tutori
 
 ## 🎓 What You'll Learn
 
-* **Microsoft.Extensions.AI abstraction** — How `IChatClient` lets you swap LLM providers by changing one line
+* **OllamaSharp streaming** — How `IOllamaApiClient` streams tokens from Ollama using `IAsyncEnumerable<>` so responses appear progressively, not all at once
 * **Ollama integration** — Pull a free local model and connect it to your .NET API in minutes
 * **Feature flag gating** — Why `[FeatureGate("AiEnabled")]` is the safest way to ship AI without breaking existing users
 * **Clean Architecture placement** — Where AI interfaces, implementations, and controllers belong in the layer structure
-* **Provider-agnostic DI** — How to register `AddOllamaChatClient()` so the rest of the app never knows which provider you're using
+* **Custom `IAiChatService` interface** — How defining your own service interface in the Application layer hides OllamaSharp from callers and makes the implementation swappable
 
 ---
 
@@ -54,16 +54,18 @@ Beyond getting started, there's an architectural risk: if your AI code reaches d
 
 ## 💡 The Solution
 
-[Microsoft.Extensions.AI](https://learn.microsoft.com/en-us/dotnet/ai/microsoft-extensions-ai) provides a single `IChatClient` interface that works identically across providers. Register `AddOllamaChatClient()` in development, `AddAzureOpenAIChatClient()` in production — your `IAiChatService` implementation doesn't change.
+[OllamaSharp](https://github.com/awaescher/OllamaSharp) is a .NET client for Ollama that exposes `IOllamaApiClient` and native token streaming via `IAsyncEnumerable<>`. We use it directly in `Infrastructure.Shared` — one package, no additional provider abstraction library needed.
 
 [Ollama](https://ollama.com) runs open-weight models like `llama3.2` locally. No API key. No cloud. Works offline. Perfect for tutorials and development.
 
+Provider independence comes from our own `IAiChatService` interface defined in the Application layer. `OllamaAiService` implements it using OllamaSharp. To swap providers (e.g., Azure OpenAI in production), you write a new implementation of `IAiChatService` in Infrastructure.Shared and change the DI registration — the Application layer, handlers, and controller are untouched.
+
 We gate the entire `AiController` behind a `[FeatureGate("AiEnabled")]` attribute. When `"AiEnabled": false` (the default), the controller doesn't even respond to requests — no Ollama connection is attempted, the rest of the API is unaffected.
 
 **Key benefits:**
 
 * ✅ **Zero cost** — Ollama is free; no API key, no credit card, no rate limits
-* ✅ **Provider-agnostic** — Swap Ollama → Azure OpenAI → Anthropic by changing one DI registration line
+* ✅ **Provider-independent Application layer** — `IAiChatService` hides OllamaSharp from all callers; swap the implementation without touching handlers or controllers
 * ✅ **Safe coexistence** — Feature flag default `false` means original tutorial (Series 0–5) works unchanged
 * ✅ **Clean Architecture** — Interface in Application, implementation in Infrastructure.Shared, controller in WebApi
 
@@ -340,7 +342,7 @@ Click **POST /api/v1/ai/chat**, then **Try it out**, and send:
 
 ![Swagger UI POST /api/v1/ai/chat endpoint — request body schema with message and systemPrompt fields](../../Tests/AngularNetTutorial-Playwright/screenshots-output/series-2-dotnet-api/swagger-ai-chat-endpoint.png)
 
-Click **POST /api/v1/ai/chat**, then **Try it out**, and send:
+Expand **POST /api/v1/ai/chat**, click **Try it out**, and send:
 
 ```json
 {
@@ -374,25 +376,27 @@ curl -X POST https://localhost:44378/api/v1/ai/chat \
 
 **After this approach:**
 
-* ✅ Swap Ollama for Azure OpenAI in production by changing one DI line — application code unchanged
+* ✅ Swap Ollama for Azure OpenAI in production by writing a new `IAiChatService` implementation and updating one DI registration — Application layer and controller unchanged
 * ✅ Zero-cost, zero-signup AI during development — every tutorial reader can follow along
 * ✅ Feature flag default `false` means the full Series 0–5 stack runs unchanged — AI is opt-in
 
 ---
 
 ## 🌟 Why This Matters
 
-The `IChatClient` abstraction from Microsoft is the `.NET HTTP Client` of AI — a standard interface the ecosystem is aligning around. By building on it now, your code is forward-compatible with whatever provider becomes the best choice in 12 months.
+OllamaSharp's native `IAsyncEnumerable<>` streaming means tokens appear progressively as Ollama generates them — critical when a local model takes several seconds per response. Buffering the entire reply before returning it would feel broken to users.
+
+The custom `IAiChatService` interface pattern is the key architectural decision. It places the Ollama dependency entirely inside `Infrastructure.Shared`. Application-layer code (handlers, queries) and the controller depend only on the interface — they are completely unaware of OllamaSharp. When you are ready to move to a cloud provider (Azure OpenAI, Anthropic), you add a new infrastructure implementation and update one DI registration. Nothing else changes.
 
 For tutorial purposes, Ollama removes the biggest barrier to learning: access. Every developer on every OS can pull `llama3.2`, type `ollama serve`, and have a working LLM in their local environment. No billing, no configuration, no waiting for API access.
 
 The feature flag pattern ensures this is safe to ship: the codebase always builds, always runs, and the original Series 0–5 experience is completely unchanged. AI features activate on demand.
 
 **Transferable skills:**
 
-* **Provider-agnostic AI abstractions** — The `IChatClient` pattern applies equally to Azure OpenAI, Anthropic, Google, and Hugging Face endpoints
+* **Custom service interface for AI** — The `IAiChatService` pattern applies to any AI provider; define the contract in Application, implement in Infrastructure
 * **Feature flag architecture** — The `[FeatureGate]` pattern applies to any experimental or optional feature
-* **Clean Architecture for external services** — Interface in Application, implementation in Infrastructure, provider registration in WebApi
+* **Clean Architecture for external services** — Interface in Application, implementation in Infrastructure, DI registration in WebApi
 
 ---