The .NET Stacks #24: Blazor readiness and James Hickey on Coravel

This week, Blazor readiness and a talk with James Hickey.

Dave Brock
Dave Brock

RIP, James Bond. While watching Goldfinger last night, I forgot about the best feature of Connery Bond films: if you’re confused about the plot, the villain will explain it all to you right before the movie ends. Ah, the original “let’s have retro before the sprint ends.”

This week:

  • Is Blazor ready for the enterprise?
  • Dev Discussions: James Hickey
  • Last week in the .NET world

Is Blazor ready for the enterprise?

If you’re writing .NET web apps, you’ve likely aware of all the Blazor hype. (If you haven’t, it allows you to write web UIs in C#, where you’ve traditionally had to use JavaScript.) In the last two years, I’ve seen it morph from a cute Microsoft project to something they’ve deemed production-ready.

And with .NET 5—becoming generally available next week!—we’re seeing a lot of great improvements with Blazor: CSS isolation, JavaScript isolation, component virtualization, toggle event support, lazy loading, server-side prerendering, and so on. These improvements help Blazor catch up to base features of leading SPA frameworks, like Vue, React, and Angular.

If you’re slinging code for a decent-sized company, you might be wondering if Blazor is ready for the enterprise. Can you convince your pointy-haired bosses to use it for new, and maybe existing, apps? I think it’s ready. However, this isn’t an “easy yes”—it involves a nuanced answer. We’ll answer this question by answering some common questions.

Is it another Silverlight? If you’ve worked in Blazor for a little while, it’s a tired argument but one you’ll have to answer from those not in the day-to-day .NET world. While a similar concept—using C# instead of JavaScript to build web apps—Blazor is built on web standards and is not built with proprietary tech that can be suddenly thrown away. It isn’t a browser plugin like Silverlight.

How will it help teams deliver faster? Blazor lowers the front-end learning curve normally associated with JavaScript, and allows devs to use their language and their tools to get things done. Blazor doesn’t replace JavaScript. However, if you’re in a shop with mostly C# devs, it’s an obvious productivity improvement. This isn’t a quick on/off switch, as teams still need to get familiar with core SPA concepts, but the use case for .NET shops is clear.

Is it supported with a good ecosystem? Because Blazor lives in the .NET ecosystem, it comes with official Microsoft support just like any other product (and, last week, we discussed .NET 5 support). Additionally, Microsoft continues to devote significant investment in it and has a long history of backwards compatibility. The ecosystem is not as evolved as it is with Angular and React—they’ve had a head start—but is growing tremendously. As Peter Vogel mentioned, Blazor already has 25% of the interest that Vue has (from Google Trends).

Does it perform well? Compared to other SPA frameworks, Blazor’s performance is … fine? It’ll pass the eye test with Vue and whatnot in most cases but there will be some waiting—Blazor Web Assembly has a large-ish download size (as its loading .NET in the browser), and Blazor Server has a network hop for each user interaction. The team has made a lot of progress in addressing performance, and AOT compilation is the most popular request for ASP.NET in .NET 6 (and will impact non-Blazor apps in ASP.NET as well). If you’re dealing with huge amounts of data, you might want to wait for these improvements—but should be suitable in most business cases.

Dev Discussions: James Hickey

When designing a real production system—especially over the web—there’s a lot to think about past coding features for stakeholders. For example, how do you manage events? What about scheduling tasks? What about your caching mechanism? A lot of these considerations make you wonder if they should be supplied out-of-the-box with ASP.NET Core.

James Hickey’s Coravel project is here to assist. Billed as a “near-zero config .NET Core library that makes task scheduling, caching, queuing, mailing, event broadcasting, and more a breeze,” it ships with an impressive set of free features—and you can look at Coravel Pro for a professional admin panel, UI management, health metrics, and more.

I caught up with James to talk about his project, software design, and more.

James Hickey

As the author of Refactoring TypeScript, what are your biggest tips on keeping a codebase healthy?

  • Simplicity rules the day. If you “feel” like your solution is getting complicated, then step back or take a 15-minute walk!
  • Reuse is over-hyped. It leads to coupling. Coupling more often-than-not causes trouble down the road.
  • Abstract I/O from other kinds of logic. Don’t do direct database or file system access from the core logic in your system. Put that behind an interface.
  • If you want to get good at designing code, then get good at knowing how to build unit tests that have minimal (or no) mocking/stubbing.
  • Use automated quality analyzers to fail builds when code standards are violated.
  • Fix broken windows.

Let’s talk about your Coravel project. I love your bold selling point: “Near-zero config .NET Core micro-framework that makes advanced application features like Task Scheduling, Caching, Queuing, Event Broadcasting, and more a breeze!” Can you walk through what caused you to pursue this project, how Coravel can help me, and how it works with existing .NET projects?

Back in the day when I was building .aspx WebForms, I discovered the PHP framework Laravel and loved how it included all these additional features like queuing, task scheduling, and so on out of the box. When .NET Core was gaining traction, I found myself wanting some of the conveniences of Laravel but in .NET Core.

Coravel can help you get a new project up-and-running faster by including things like automated task scheduling, background task queuing, and so on out of the box without having to install extra infrastructure. It works with any .NET Core projects and is (supposed to be) super easy to install, configure and use.

For scheduling and event management, I know a lot of folks like utilizing things like triggered Azure Functions and Service Bus and the like—is there an advantage to using Coravel over that?

One disadvantage is that Coravel doesn’t (yet!) support distributed scheduling, queuing, and caching features. One advantage though, again, is you don’t have to install any additional infrastructure. You can install a NuGet package, add a couple lines of code and you’re good-to-go!

You can use Coravel and these other products together, too. For example, we often use a distributed service bus to integrate separate systems via async messaging. Coravel can support the internal integration within a system—like how you might emit domain events between aggregates. Doing this in-memory has certain advantages. Jimmy Bogard, for example, has written about using in-memory domain event processing.

I know by default, Coravel caching is in-memory (but has options to persist to a database). How does this compare to something like Redis?

Again, using Coravel you won’t have to muck around with installing, configuring, and so on with that additional infrastructure. Redis is a fantastic product and I’m hoping to eventually offer providers for Coravel to hook into Redis—which could make using Redis caching, messaging, and so on even easier. I just need to find some time 😉.

Do you view Coravel as an enhancement over the BCL, or filling in for some of its shortcomings? This is part of a broader thought about OSS’s role within .NET Core.

I view Coravel as enhancements over the BCL. I wouldn’t expect to see these features included in a barebones console application, for example. But when it comes to web applications, these are all features that you’ll need pretty much out-of-the-gate if it’s anything more than a demo application.

I’m a fan of your “Loosely Coupled Show” that you run with Derek Comartin (sure beats the “Tightly Coupled Show”)—a great spot to discuss software architecture and design. In such a fluid industry, are there any firm principles you are stubborn about?

Generally, I stick with using a feature folder approach to structuring any projects I work on. I’ve written about this before and Derek just wrote about it. I’m a huge fan of CQRS and think it fits perfectly with the feature folders approach.

I’ve given a talk on these topics at the Florida .NET meetup if anyone’s interested in hearing more about it.

Check out the full interview at my website.

What is your one piece of programming advice?

Make sure you get lots of sleep and step outside once in a while. 😅

🌎 Last week in the .NET world

🔥 The Top 5

📢 Announcements

📅 Community and events

😎 ASP.NET Core / Blazor

⛅ The cloud

📔 C#

🔧 Tools

📱 Xamarin

🎤 Podcasts

The 6-Figure Developer podcast talks about managing cloud cost with Omry Hay.

🎥 Videos

.NET Stacks