Hi folks!

Are you pulling your hair out deciding on how to go about a new Blazor application?

Don’t worry, having worked in .NET since it’s birth too many decades ago, my career has spanned the evolution of the Internet right through to modern day reactive web apps.

My best advice is to invest in “simple”.

Consider the application you need – is it to manage your flower shop, or tackle the complex needs of an oil and gas operator?

As software engineers we have a habit of overengineering (because we’re too smart for our own good), and I’ve seen the drastic effects of this over a career which has spanned 4 decades.

Don’t do it.

Keep it simple.

This leads me to my recommendation. So, if you’re looking to build a Blazor web app in 2025, here’s a clean and modern way to do it:

Overview

Given UI technologies change rapidly (Angular -> React -> Blazor, and so on) it’s well worth segregating your business logic and data into an API.

Data rarely changes, right?

In 2025 I would opt for GraphQL – it has inherent benefits over WebAPI with Swagger, such as more efficient data access, and the ability for the UI to get exactly the data it needs rather than a load of unnecessary stuff it doesn’t.

Therefore, consider a BACKEND using the following:

• Entity Framework code first (because it’s tried and tested)
• HotChocolate .NET as the most popular GraphQL package (because, trust me, it’s all you need)

For the front end, we’ll also keep it simple:

• Blazor – Web Assembly or Server depends on your needs, with the key point being this 👉 All your end user cares about is they can do their job.
• Optional: I highly recommend investing in professional 3rd Party Controls. Don’t spend months reinventing a wheel only to end up with a square wheel (this is what most companies do to save money, when the reality is it costs much more and you end up with a rubbish application.

Is the above resonating with you? If not, please let me know why in the comments – there are no right answers.

Let’s get into a bit more detail…

Backend: GraphQL with Entity Framework and HotChocolate

At the core, build your backend as a GraphQL API using HotChocolate for .NET.

HotChocolate is fast, works really well with Entity Framework, and lets you query data with minimal effort and a great deal of flexibility.

You get:

• A single endpoint for all your data needs
• Automatic schema generation from your models
• Strong typing across client and server
• Excellent integration with authentication and validation
• Oh, and your web app can hook up to events (subscriptions), so if data changes elsewhere, your user is notified immediately.

For validation, FluentValidation works well with HotChocolate. Personally I have been using FairyBread which works perfectly (I had awkward versioning issues with alternatives, but they all keep business rules clean and testable).

FluentValidation also ties in neatly with authentication logic when you need to protect specific fields or mutations.

Blazor front end: “Keep It Thin”

It’s not a term used much these days, but a web app should always be a “Thin Client”.

By this I mean all the complex business logic and data management is offloaded to the API, which means all the Blazor web app needs to do is get data from here and display it there.

This protects you from new and fancy future technologies – you simply scrap your Blazor app and replace it with React II or whatever it may be (although I’m sure your Blazor app will be great enough to outlast new technologies, assuming it gives your users what they need).

You can use Strawberry Shake (from the same team behind HotChocolate) which has code gen (it will create you a Client end int), or another GraphQL client to connect directly to your API (such as GraphQL.Client which lets you chuck regular queries and mutations at your endpoint).

Whatever you choose, you will find they can all tie in well with UI components or a 3d Party control library.

UI Controls: INVEST in 3rd Party Controls

Don’t reinvent the wheel.

Way back in 2007 I worked for a company who weren’t willing to use a FREE Ajax (old tech, I know) tab control because they wanted it to look a bit different – not that end users would care.

Instead they paid a contractor big bucks to create their own tab control in-house.

6 months later, as a fellow contractor, we would laugh about how much they’d paid him to do it… not that he ever got it working.

Invest in professional 3rd party controls!

It’s an absolute no-brainer and absolute money saver.

The top three worth considering in 2025 are:

• Telerik UI for Blazor – Very professional, mature, feature-rich, and well-documented. I persuaded a company to use Telerik UI on an application I designed and implemented – it led to awards which kept the entire company running, made $17 million Aussie dollars, and that convinced them to use Telerik UI on all future developments.
• Syncfusion Blazor Components – Developed in India, I found Syncfusion a little ropey a few years ago, but it’s come on a long way since, is cheaper than Telerik, and has an enormous range of controls – great value for money too.
• DevExpress Blazor – I confess to never using DevExpress, but it’s been around for many years, clearly polished, enterprise-ready, and I believe ideal for reporting and dashboards

Honestly, you may struggle to convince “management” to spend money on a control suite, but the alternative is weeks of development and money down the drain.

Optional: CQRS and MediatR

I’ve been a big fan of CQRS, MediatR, an “Clean Architecture” in the past, but feel – for the sake of simplicity – this probably isn’t needed unless your application will have complex business logic.

If your application will be complex, it’s well worth looking into Clean Architecture, and wrapping your business logic in CQRS commands and queries.

If your application is simple, why bother with all that jazz?

Certainly, for simple CRUD-style data services, it’s utterly overkill.

Stick to straightforward GraphQL resolvers until your logic genuinely warrants extra complexity, and worry about it then (if that ever happens).

Why this stack works

• Modern: built entirely on .NET 8+
• Clean: GraphQL enforces structure without overcomplication
• Scalable: works on-premises or in the cloud (Azure, AWS, wherever you deploy)
• Maintainable: clear separation between UI, logic, and data layers

In short:

Blazor + HotChocolate GraphQL + EF + Strawberry Shake = a modern .NET stack that feels effortless once you’ve set it up properly.

It’s also cloud ready – whatever f*cking cloud you want to stick it in.

What are your thoughts?