Full-stack .NET: building a complete web application from Blazor to APIs with a single language, C#

Thomas has eight years of pure backend work behind him, and today he is looking at his first full-stack .NET project.

He can write endpoints that hold up under millions of rows.

But the moment someone asks him to wire the frontend to the APIs, handle login end to end and push the whole thing into production, he freezes.

Not because he lacks skill. Because he has learned one layer exceptionally well, and one layer on its own delivers nothing.

The problem is not Thomas. The problem has a name: the half-finished developer.

That is the developer who masters one slice of the stack and, for everything else, has to wait for somebody else.

In a large company with a dedicated team per layer, that developer survives. In a small business, a startup or a digital agency, where the team is tiny and deadlines are short, that developer becomes the bottleneck.

The one who opens a ticket and waits. The one you trust with half a feature, never a whole one.

If this is where you are, it is not your fault.

For years we were told that specialising was the way forward. Then the market shifted and started paying the people who deliver, not the people who know.

The good news is that in the Microsoft ecosystem this change has never been cheaper to make, because you make it with a single language.

With C# you write data access, business logic, Web APIs and, thanks to Blazor, even the frontend.

In this article I show you how a full-stack .NET application holds together, layer by layer. And why the developer who can cross all of them earns more and stays relevant, while the others wait for a ticket.

What full-stack .NET means: who is really a full-stack developer

Let us start with the question everyone types into Google and ChatGPT: what does full stack actually mean, and what does a full-stack developer do?

The short answer is everywhere. The one that matters is not.

Full stack means being able to build every layer of a web application: the frontend the user touches, the backend that exposes data and applies the rules, the data access that talks to the database, the authentication that protects it all and the infrastructure it runs on.

A full-stack developer is someone who takes a feature from the interface all the way to the row saved in the database, and back, without passing the ball to three different people.

Most developers think full stack means "knowing a lot of technologies". In reality it means one thing only: knowing how to connect the parts.

You can know React, Node and EF Core and still be a half-finished developer, if every time the parts have to talk to each other you need somebody else.

Full-stack skill is not measured in tools you know, it is measured in flows you can close on your own.

In the .NET world this skill is unusually solid, and the reason is the single language.

In a mixed stack such as React plus Node, or Angular plus any backend, you live in two worlds: TypeScript on one side, the backend language on the other.

You keep types aligned by hand, duplicate data models, maintain two toolchains and two package ecosystems, each with its own security issues and upgrade cycles.

Every border between those two worlds is a place where things break.

With full-stack .NET built on Blazor, the C# model is one and the same: you define it once and it travels unchanged from the frontend to the APIs and down to data access. No duplication, no drift, no mental jump between languages.

This does not mean Blazor is always the right call, and further down you will see when a JavaScript framework remains the better choice.

It means that, when the context allows it, full-stack development in C# strips out accidental complexity and leaves you energy for the real thing: the business domain.

The time you do not spend picking a stack goes into the feature the client is waiting for.

How to organise the architecture of a full-stack .NET project

Before you write a single line of code, you need a map.

A full-stack .NET application done properly is not one big project where controllers, SQL queries and business rules blend into a paste. It is a layered architecture with clear responsibilities and controlled dependencies.

And here comes the first blow to the half-finished developer: when the layers are cleanly separated, a single developer can move across all of them without getting lost.

The reference model, inspired by Clean Architecture, splits four responsibilities into four projects in the solution.

Domain: the core with no dependencies

The Domain project holds the business entities and the pure rules: an order, a customer, a product, with their invariants. An order cannot have a negative quantity, a deactivated customer cannot buy.

This layer knows nothing about the database, nothing about ASP.NET Core, nothing about any external library. It is plain C#.

If tomorrow you change database or web framework, the Domain stays untouched.

Application: the use cases

The Application project handles the operations: create an order, record a payment, generate the monthly report.

It defines the interfaces of the services it needs, but does not implement them, and depends only on the Domain.

This is where the logic lives that coordinates entities to complete a full use case, without knowing anything about how the data is stored.

Infrastructure: the technical details

The Infrastructure project implements the interfaces defined by the Application: the concrete repository with Entity Framework Core, sending email, calling an external service.

This is where the DbContext, the entity configurations and the migrations live.

It depends on Application and Domain, never the other way round.

Presentation: APIs and frontend

The presentation layer in a full-stack app is a double one: the ASP.NET Core Web APIs that expose the HTTP endpoints, and the Blazor frontend that consumes them.

It translates external requests into calls to use cases, and nothing more.

No business rule lives here.

A layered architecture is not about looking elegant: it is about being able to change database, framework or frontend without rewriting the business logic, and about testing the core of the system in milliseconds.

There is one golden rule: dependencies always point inward, towards the Domain.

The Domain does not know a database exists, the Application does not know ASP.NET Core exists.

This separation is not academic vanity: it is what lets the system grow without every change breaking three other things.

You can understand an architecture like this by reading. You only internalise it by building it on a real project, one mistake at a time.

The Web Development course starts exactly here: layers, dependencies and responsibilities applied to a real application.

The backend: ASP.NET Core and the Web APIs that hold everything up

The backend is the backbone of a full-stack .NET application.

Even when the frontend is Blazor, it is the backend that guards the business logic, the data access and the security rules.

ASP.NET Core is the framework you build it with, and it is a mature, high-performance web framework.

The modern way to expose an API is Minimal APIs for simple endpoints, or Controllers for more structured scenarios with many routes and complex binding.

The principle is identical in both cases: an endpoint receives an HTTP request, validates it, calls the right use case in the Application layer and returns a JSON response with the correct status code.

Few things, done well.

A well-designed endpoint contains no business logic: it delegates to the application services. It never talks to the database directly: it goes through the repository interfaces.

Its only job is translating the HTTP protocol into calls to the domain, and back.

Three practices separate an amateur backend from a professional one:

• Centralised error handling: a middleware or a standardised ProblemDetails, so the client always gets consistent responses.
• Explicit input validation: FluentValidation or data annotations, before the data reaches the logic.
• API versioning from day one: a public API that changes without a version breaks the clients using it.

This is also where the backend defines the contract: the DTOs that go in and out of the endpoints.

• Never expose Domain entities through the APIs.
• Entities carry rules and relationships that must not leak outside.
• DTOs are the public face, entities stay private.

This distinction separates those who have understood the architecture from those who are merely getting the code to run: as long as the public contract stays stable, you can refactor the internal entities without breaking a single client.

The frontend specialist who does not understand what the API returns is stuck at the first 400 error.

Data access: Entity Framework Core and choosing the database

Under the backend sits the database, and in between sits Entity Framework Core, the official ORM of .NET.

EF Core turns your C# classes into tables, your LINQ queries into SQL, and tracks changes so it can generate the right INSERT, UPDATE and DELETE statements.

It lets you work with data thinking in objects, not in SQL strings glued together by hand.

The heart of EF Core is the DbContext: the class that represents a session with the database and exposes the entities as DbSet properties.

Entity configuration, meaning keys, relationships, constraints and lengths, is done with the Fluent API in dedicated classes, so you never pollute the Domain entities with persistence attributes.

The Domain stays clean, the Infrastructure carries the weight of the details.

Migrations are the mechanism that lets you evolve the schema in a versioned way.

Every time you change the model you generate a migration describing the incremental change, and you apply it with a single command.

The schema ends up under version control alongside the code, and you get rid of the classic drama of "it works on staging, not in production".

There are traps that separate a naive use of EF Core from a deliberate one.

The N+1 query problem, where loading a list and then touching a navigation property fires one query per item, is solved with Include or with targeted projections.

For read-only queries it pays to switch off change tracking (AsNoTracking): EF Core no longer has to create the comparison copies it uses to detect changes, so it allocates less memory and returns results faster.

Projections with Select into a DTO avoid loading columns you do not need into memory.

These are details that never produce a compiler error: they produce slowness in production, months later.

Choosing the database depends on the context:

• SQL Server and Azure SQL remain the default for transactional relational data in the corporate .NET world.
• PostgreSQL is worth it when you need types such as JSONB for semi-structured data. On Azure you use the managed version, Azure Database for PostgreSQL, on the same EF Core provider: the data access code stays practically identical.
• For specific scenarios, Cosmos DB comes in for global scale and Redis for caching.
• EF Core supports several providers, but the layered model isolates that choice inside the Infrastructure: the rest of the application does not even notice. And this is exactly where the frontend-only developer runs aground.

A developer who cannot read a slow query or design a migration cannot finish a feature alone: there is always someone else needed for the last mile.

Reading about how EF Core works is one thing. Designing the data access of a real application, with its critical queries and its migrations in production, without asking for help at every step, is another.

The gap between the two is closed with a method, not with yet another tutorial.

On our C# and web development path you cross every layer by building a real application, until you stop being the specialist who waits and become the developer who delivers.

The frontend with Blazor: web development in C# without switching language

Here comes the part that makes full-stack .NET development genuinely distinctive.

With Blazor the frontend is written in C# and built from reusable components, exactly as you would with React or Angular, but without leaving the language of the backend.

A Blazor component is a .razor file that mixes HTML markup, C# logic and data binding in a declarative way.

Blazor comes in two main hosting models, and understanding the difference is essential, because it radically changes how the frontend connects to the backend.

Blazor WebAssembly

With Blazor WebAssembly the application is compiled to WebAssembly and runs entirely in the user's browser, like a single page application.

The frontend is a self-contained client that talks to the backend through HTTP calls to the Web APIs, using HttpClient.

It is the model closest to a classic JavaScript architecture: the client is separate from the server, it scales well because rendering happens on the user's device, and it even works offline once loaded.

Blazor Server

With Blazor Server the rendering happens on the server and interface updates travel to the browser over a persistent SignalR connection.

The strengths and limits of the two models are clearest side by side:

From .NET 8 onwards Blazor unifies the two worlds with render modes, letting you choose per component whether to render on the server, on the client or statically.

That gives you real flexibility: public pages rendered on the server for SEO and speed, private interactive areas running in WebAssembly.

The biggest architectural benefit of Blazor in a full-stack context is model sharing.

The DTOs the backend uses for its APIs are defined in a Shared project, and the Blazor frontend references them directly.

When you add a field to a DTO, frontend and backend see it at the same instant, with the same C# type, with no manual duplication.

Anyone who has kept TypeScript types aligned with backend models by hand knows how much this removes an entire class of bugs.

If writing the frontend in C# feels like the right road, the next step is getting your hands on it: components, binding, routing and state are learned by building.

That is the route you follow in the Web Development course, where Blazor arrives once the backend and the APIs are already solid under your fingers.

How frontend, APIs and database connect in a full-stack .NET application

All the theory about layers starts to make sense when you follow a single request from start to finish.

This is where the half-finished developer is exposed for what they are: capable on one piece, silent on all the others.

Picture a user in the Blazor frontend filling in a form to create an order and pressing Confirm.

What happens, layer by layer?

In the frontend, the Blazor component collects the form data into a DTO object, the very same C# type the backend expects.

With Blazor WebAssembly the component calls httpClient.PostAsJsonAsync("/api/orders", dto): the DTO is serialised to JSON and sent over HTTP.

With Blazor Server the same component would call the application service directly, without going through HTTP.

The request reaches the ASP.NET Core backend. The authentication middleware validates the token in the header and checks that the user has the right permissions.

The endpoint receives the deserialised DTO, validates it and calls the application service, for example orderService.CreateAsync(...).

In the Application layer the service orchestrates the use case: it creates the Domain Order entity applying its rules, checks that the items are available, works out the total, then calls the IOrderRepository interface to persist the result.

It knows nothing about HTTP, nor about which database sits underneath.

The concrete repository implementation, in the Infrastructure, uses EF Core to add the entity to the DbContext and call SaveChangesAsync(), which generates and runs the INSERT against the database.

The generated id travels back up the chain to the endpoint, which responds with a 201 Created and the id of the new order.

The frontend receives the response, updates the interface and shows the confirmation to the user.

Nobody pays you for knowing Blazor or EF Core. They pay you because a request leaves a button and comes back resolved from the database, and you can make that whole chain happen on your own.

The beautiful part is that along the entire route you used a single language.

The DTO is the same C# object from the Blazor form to the endpoint. No mental translation between JavaScript and C#, no duplicated model to keep in sync.

The half-finished developer knows one box in this diagram and opens a ticket for the others. The full-stack developer crosses them all, which is why in a small team they are worth twice as much.

JWT authentication and Entra ID in a full-stack architecture

A real web application has to know who the user is, that is authentication, and what they are allowed to do, that is authorisation.

In .NET this is built on well-established components, and understanding how they fit together is what stops you leaving security holes wide open.

The usual starting point is ASP.NET Core Identity: the built-in system for managing users, passwords with secure hashing, email confirmation, password reset, lockout after failed attempts and roles.

Identity relies on EF Core to persist users and roles, and slots naturally into the Infrastructure layer of the architecture described above. One single place where identity lives, not scattered everywhere.

To authenticate Web API calls from a Blazor WebAssembly frontend or an external client, the standard is JWT tokens.

The flow is straightforward:

• Login: the user sends their credentials and the backend checks them with Identity.
• Issue: if the credentials are valid, the backend generates a signed JWT token holding the user claims, meaning id, roles and expiry.
• Send: the frontend stores the token and attaches it to the Authorization: Bearer ... header of every following request.
• Verify: on every call, the backend validates the signature and the claims before authorising.

Authorisation is expressed declaratively. You can protect an endpoint with [Authorize], require a role with [Authorize(Roles = "Admin")], or define richer policies based on claims.

Policies are the most powerful tool: they separate the authorisation decision from the endpoint logic and are configured in one single place.

For more complex scenarios, multi-application or aimed at external users, it pays to delegate identity to a dedicated provider such as Microsoft Entra ID, formerly Azure AD, Entra External ID for consumer users, or any OpenID Connect solution. That way you are not managing passwords yourself, you get corporate single sign-on and you fit into the organisation's security policies.

The architectural principle stays the same: the backend validates the tokens, the frontend attaches them, the endpoints check the policies.

There is one mistake that early full-stack projects make every single time: putting the authorisation logic in the frontend and assuming that is enough.

Hiding a button from someone without permission is good user experience, but it is not security. The frontend is under the client's control and can be bypassed.

The rule is blunt: the frontend decides what to show, the backend decides what to allow.

Someone who only knows the interface does not see that distinction, and opens the hole without noticing.

Testing and quality: why a layered architecture really pays off

All that work separating layers finds its most concrete justification in testing.

A well-structured full-stack .NET application is testable at several levels, and each level covers a different class of problems.

Anyone who has drowned the logic inside controllers does not get that luxury.

Unit tests cover Domain and Application: you check that the business rules are correct, for instance that an order with a negative quantity is rejected and that the total is calculated properly, without touching database or network.

These tests are extremely fast and numerous, because the Domain has no external dependencies.

This is where keeping the logic isolated shows its value: you test it in milliseconds, without spinning up any infrastructure.

Integration tests verify that the layers really do fit together: they use a real database, a test container or an in-memory database for the simple cases, to check that the EF Core queries produce the expected results and that the migrations are consistent.

ASP.NET Core offers WebApplicationFactory to start the whole application in memory and test the endpoints from the outside, the way a real client would, authentication included.

End-to-end tests, finally, drive the Blazor frontend the way a user would, with tools such as Playwright, and check that the whole flow, from click to database and back, works. They are the slowest and most brittle, so you keep few of them, aimed at the critical paths.

They are not there to cover everything: they are there to protect the two or three routes that must never break.

A clean layered architecture makes logic tests instant and reliable, and that translates into fewer bugs in production and refactoring without fear.

An application where the logic is scattered between controllers and SQL queries is almost impossible to test well: every test needs the whole infrastructure standing up, and in the end nobody writes them.

Quality is not only automated tests. It is also static analysis with the Roslyn analyzers, code review on design decisions and a pipeline that blocks the merge when tests fail.

Which takes us straight to the final layer, where tests become the first gate of every release.

Containers and deploying to Azure: full-stack .NET in production

An application only truly exists once it is in production and somebody is using it.

Release is the final layer, and it is also the one the half-finished developer almost never touches: they hand over their piece and disappear before go-live.

In .NET you have several mature options, depending on the context.

The most direct option in the Microsoft world is Azure App Service: a managed service where you publish the ASP.NET Core application without thinking about the operating system or the web server. It handles scaling, HTTPS certificates, staging slots for releasing without downtime, and it integrates with the rest of Azure.

For many line-of-business applications it is the fastest and most sensible choice.

The modern, portable alternative is Docker containers. You package the application and all its dependencies into an image that runs identically on your laptop, on staging and in production.

Containers are then orchestrated with Azure Container Apps for serverless scenarios with automatic scaling, or with Kubernetes through AKS for complex systems with many services.

The benefit is independence from the cloud provider: the same image runs anywhere, and you are nobody's hostage.

Releasing is not a manual gesture.

A CI/CD pipeline, with GitHub Actions or Azure DevOps, automates the lot: on every push it compiles the code, runs unit and integration tests, builds the image, applies the database migrations, and releases to production only when everything is green.

EF Core migrations in production need care: they are applied in a controlled way, with a strategy that does not lock the application and that can be rolled back.

Some elements must never be skipped.

Secret management, meaning connection strings and keys, has to go through Azure Key Vault or environment variables, never through files committed to the repository.

Observability with Application Insights gives you structured logs, metrics and request tracing, which are indispensable when something goes wrong at two in the morning.

And health checks, meaning an endpoint that answers "I am alive and working" and that the platform polls continuously to decide whether an instance should stay in service or be restarted, expose the state of the application and of its dependencies, so the orchestrator knows when an instance is unhealthy and replaces it.

The Blazor WebAssembly frontend, once compiled, is static: you serve it from the same backend or you distribute it on a CDN for maximum speed.

Blazor Server, which depends on the SignalR connection, instead needs attention to session handling when you scale across several instances, typically with a Redis backplane, meaning a shared channel that synchronises the SignalR state across the different instances of the application.

These are infrastructure decisions the full-stack developer takes personally, not tasks they wait on somebody else for.

Taking those decisions personally is what separates the person who delivers an application from the person who delivers only code. In the Web Development course deploying to Azure is not a closing footnote: it is part of the path, pipelines and migrations included.

Blazor or JavaScript: when to choose which in full-stack .NET

It would be dishonest to present Blazor as the answer to every situation.

A good full-stack developer picks the tool for the context, not for the fashion.

The right question is not "is Blazor better than React", but "for this project, with this team and these requirements, what actually pays off".

Blazor shines in specific scenarios. Internal line-of-business applications, corporate portals, dashboards, back offices: contexts where user experience matters but does not have to compete with a world-class consumer app, and where team productivity and maintainability outweigh everything else.

It shines when the team is already strong in .NET, and spending months moving them to React makes no economic sense.

It shines when sharing models between frontend and backend removes a constant source of bugs.

A JavaScript framework remains preferable in other cases.

When you need a vast, mature ecosystem of UI components, with a library for every visual need.

When the team already has solid React or Angular skills and retraining them would cost a fortune.

When the application is public and has SEO and first-load performance requirements so demanding that they call for the fine-grained control that JavaScript stacks with server-side rendering currently offer in a more battle-tested way.

The decisive architectural advantage is that the choice of frontend does not lock in the backend: you swap the client without touching a line of business logic, because the ASP.NET Core backend serves the same JSON to Blazor as it does to React.

That means even if you pick React today, your full-stack .NET skills on the backend, the APIs, EF Core, authentication and release stay fully valid and central. And if tomorrow you want to try Blazor on a new module, you plug it into the same APIs without upending anything.

This decoupling is one of the reasons the .NET stack sustains applications that have to last for years. And the difference between deciding on merit and following the hype is, once again, how much of the whole system you can see, not how much of a single layer.

How much does a full-stack developer earn

Now for the question that matters for your career: how much does a full-stack developer earn, and is it worth investing in?

In 2026, companies on the Microsoft ecosystem are actively looking for people who can take a feature from the interface to the database, without coordinating three specialists for every line.

Italy is a useful example of a mid-sized European market, and the figures there show a wide spread, moved above all by seniority:

The data comes from Glassdoor Italy and Indeed Italy, updated to June 2026.

The jump between the two ends of that spread is not decided by years served: it is decided by how many layers you can close on your own.

The .NET specialisation pushes in the same direction.

It is in high demand in enterprises and in smaller companies running line-of-business systems built on the Microsoft ecosystem, where changing stack is not a realistic option, and that places full-stack .NET profiles in the upper-middle part of the bands above.

Remote work has then widened this market far beyond your own city: an employer in one city hires someone hundreds of kilometres away without thinking twice, as long as that person delivers.

The reason is simple: someone who delivers a whole flow is worth more than someone who guards one piece of it.

A company hiring a single-layer specialist has to build the rest of the team around them.

A company hiring a full-stack .NET developer is buying the finished feature, and that shows up in the number it is willing to put on the table.

The spread you have just seen is not crossed by adding technologies to your CV, but by adding layers you can close on your own. The Web Development course is built exactly for that: taking you from a single layer to the complete flow.

How to become a full-stack .NET developer without spreading yourself thin

Knowing what this profile is worth is one thing, building it is another.

And here most developers take the wrong road in exactly the same way.

The classic trap is studying every technology in isolation: a month on EF Core, one on Blazor, one on authentication, piling up knowledge that never connects.

It is the slowest and most frustrating way, and it is precisely what manufactures blocking specialists instead of self-sufficient developers.

The effective route is the opposite: building a complete application from the very start, even a small and imperfect one, that crosses all the layers.

A simple task manager with login, database persistence, APIs and a Blazor frontend teaches you more connected knowledge than months of fragmented study.

By crossing the whole flow, from pressing a button to the saved row and back, you genuinely understand how the parts talk to each other.

A sensible sequence starts from solid C# foundations, meaning object-oriented programming, LINQ, async and await, then tackles ASP.NET Core and the Web APIs to get a working backend, adds EF Core and the database for persistence, brings in Blazor for the frontend, and closes with authentication and release.

At every stage the application you are building grows and becomes more real.

Then there is the question of cost: how much does a full-stack training path cost, and is it worth it?

The honest answer is that the cost has to be compared with the alternative, not looked at on its own.

The alternative is learning on your own, with the weeks lost on trivial problems, the wrong architectural choices discovered too late and the bad habits that turn into technical debt you struggle to correct.

The difference between someone who becomes full stack in six months and someone who takes two years is not talent: it is having a guide who shows you the right choices before the mistakes settle in.

Two years spent at the bottom of that pay range instead of the top is tens of thousands lost, and no training path costs that much.

One language, the whole application, you delivering it

We have crossed every layer of a full-stack .NET application: the frontend with Blazor, the backend with ASP.NET Core and the Web APIs, data access with Entity Framework Core, authentication with Identity and JWT tokens, all the way to releasing on Azure and in containers. And we did it while staying inside a single language, C#, and a single coherent architecture.

That is the deep value of full-stack development in .NET: it is not doing a bit of everything badly, it is being able to do it with continuity, without the jumps and the duplication that wear down anyone living across two ecosystems.

Models are shared, the tools are the same, the mental model is one.

The energy you save on accidental complexity goes into the real problem: the domain and the user's experience.

Come back to Thomas, the one from the opening, stuck in front of a full-stack project with eight years of pure backend behind him.

Every month he spends guarding a single layer is a month in which his market value stands still, while the colleague who delivers whole flows moves up.

It is not a question of intelligence: it is a question of how much of the system he can see and close on his own.

The half-finished developer is not a destiny, it is a phase you leave behind with the right method.

The decisions that count have run through this whole article: separating the layers with dependencies pointing inward, never exposing Domain entities through the APIs, putting security on the backend and not in the frontend, testing at several levels, automating the release.

These are the choices that separate an application that lasts for years from one that becomes unmanageable in months, and a developer who delivers from one who waits.

We build the full-stack .NET profile starting from solid C# foundations and walking with you, layer after layer, up to complete applications, with mentoring from people who have put these systems into production.

Matteo works directly on the paths, so the places cannot be unlimited by definition: access is by application, not by sign-up.

The Thomas of the opening is not a character: he is a photograph of anyone who has learned everything about one single layer.

Every missing piece, from the Blazor frontend to the Azure release, is a skill you build, not a talent you either have or do not.

The real question is only one: build it alone, with the time and the mistakes you have just seen accounted for, or with people who have already walked that road and walk it every day.

The Web Development course exists for the second option: a real application in your hands, growing with you up to the complete flow, from the button pressed to the row saved and back.

If you recognised yourself in Thomas, apply: in the worst case you find out precisely which layers you are missing.

In the best case, the next full-stack project that lands on your desk will not be a problem: you will deliver it.