Roadmap for learning .NET to build APIs

NET 10 is the current LTS release, so that's the target version for the roadmap below. Since you already work with Laravel/Filament, Django REST, and React, I'll skip the "what is a variable" stuff and focus on getting you productive with ASP.NET Core Web API quickly, mapping concepts to what you already know where it helps.

Roadmap

Phase 1 — C# fundamentals (3–5 days if you push)

• Syntax, types, var, nullable reference types (string?) — this is stricter than PHP/Python, get comfortable with it early

• Classes, interfaces, records (record types are huge in modern C# for DTOs)

• LINQ — this is the equivalent of Eloquent query builder / Django ORM querysets, but functional-style over any IEnumerable. Spend real time here; it's used everywhere.

• async/await and Task<T> — conceptually like JS async/await, but the compiler enforces it more strictly

• Generics and dependency injection basics (built into .NET, not a package like in PHP)

Phase 2 — ASP.NET Core Web API basics (1 week)

• dotnet new webapi — scaffold a minimal API project

• Minimal APIs vs Controller-based APIs (.NET 10 favors Minimal APIs for most new services; controllers still fine for larger apps — similar tradeoff to Laravel routes/closures vs full Resource Controllers)

• Routing, model binding, [FromBody]/[FromQuery]/[FromRoute]

• Built-in dependency injection container — register services as Scoped/Transient/Singleton (roughly maps to how you'd think about request-lifetime vs shared services)

• appsettings.json + appsettings.{Environment}.json for config (like .env but structured/hierarchical)

Phase 3 — Data access (1–2 weeks)

• Entity Framework Core — the ORM. DbContext, DbSet<T>, migrations (dotnet ef migrations add, dotnet ef database update) — very close conceptually to Eloquent migrations

• Fluent API vs Data Annotations for model configuration

• Given your Sage ERP / SQL Server background, EF Core's SQL Server provider will feel familiar — you can also drop to raw SQL via FromSqlRaw when EF gets in the way, same escape hatch you're used to

• Repository pattern — optional in small apps, common in larger ones

Phase 4 — API essentials (1–2 weeks)

• Model validation (Data Annotations or FluentValidation package)

• Global exception handling middleware

• API versioning

• Swagger/OpenAPI (Swashbuckle or the new built-in Microsoft.AspNetCore.OpenApi) — auto-generated docs, similar spirit to what Filament gives you for admin UIs but for API contracts

• CORS configuration (you'll need this immediately since your frontends are separate React/Livewire apps)

Phase 5 — Auth (1 week)

• JWT Bearer authentication — Microsoft.AspNetCore.Authentication.JwtBearer

• ASP.NET Core Identity if you need full user management, or roll your own if you just need stateless API auth

• [Authorize] attribute + policy-based authorization (roles/claims)

Phase 6 — Testing and structure (1 week)

• xUnit for unit tests, WebApplicationFactory for integration tests

• Clean/layered architecture: separate projects for API, Application/Services, Domain, Infrastructure (EF Core) — this pays off once a project grows past a few controllers

• AutoMapper or manual mapping between entities and DTOs

Phase 7 — Production concerns (ongoing)

• Structured logging (Serilog is the de facto standard, writes to console/file/Seq)

• Health checks (/health endpoint, built-in middleware)

• Rate limiting (built into ASP.NET Core since .NET 7+)

• Docker containerization — dotnet publish + a slim runtime image

• Deployment: IIS, Docker/Kubernetes, or Azure App Service. Note for your cPanel-hosting habits: .NET does not run on typical cPanel shared hosting the way PHP does. You'll need a VPS with Kestrel behind Nginx/Apache as reverse proxy, or a proper hosting target — this is the one part of your usual deploy workflow that won't carry over.

Best practices

• Use records for DTOs — immutable, concise, built-in value equality: public record CreateOrderDto(int ProductId, int Quantity);

• Never expose EF entities directly from endpoints — always map to DTOs, same discipline as not returning Eloquent models raw from an API resource

• Use IActionResult/Results<T> return types consistently so response types are explicit and Swagger docs stay accurate

• Async all the way down for I/O-bound work (DB calls, HTTP calls) — avoid blocking with .Result or .Wait(), it can deadlock

• Centralize error handling in middleware rather than try/catch in every action

• Use CancellationToken parameters in async endpoint methods and pass them through to EF/HTTP calls

• Configuration via IOptions<T> pattern instead of reading IConfiguration directly everywhere — keeps settings strongly typed and testable

• Keep controllers/endpoints thin — push logic into services; controllers should just orchestrate

• Use EF Core migrations from day one, never hand-edit schema, and treat migrations as they deserve — reviewed and committed like code

• Pin to .NET 10 LTS for anything long-lived; it has three years of support versus two for the in-between (STS) releases, which matters a lot for the kind of maintained-for-years apps you build (AgriDrone Atlas, Intercocina, etc.)

If you want, I can put together a small end-to-end sample (Minimal API + EF Core + SQL Server + JWT auth) so you have a working skeleton to build from rather than starting from a blank scaffold — useful if you're thinking about wiring this up to something Sage-related, given your SQL Server background.