Roundup #60: gRPC vs HTTP APIs, .NET Perception, Rider, WebWindow

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

gRPC vs HTTP APIs

ASP.NET Core now enables developers to build gRPC services. gRPC is an opinionated contract-first remote procedure call framework, with a focus on performance and developer productivity. gRPC integrates with ASP.NET Core 3.0, so you can use your existing ASP.NET Core logging, configuration, authentication patterns to build new gRPC services.

Link: https://devblogs.microsoft.com/aspnet/grpc-vs-http-apis/

Perception of .NET

I thought this thread was fascinating. Very interesting to read some of the responses.

Link: https://twitter.com/joepetrakovich/status/1195941775342493696

Rider with Kirill Skrygan

In this episode I interviewed Kirill about Rider and ReSharper from JetBrains. Some of you may know Kirill from his work on both the ReShrarper and Rider projects, and some of his work on the JetBrains open source projects.

Link: https://dotnetcore.show/episode-38-rider-with-kirill-skyrgan/

Meet WebWindow, a cross-platform webview library for .NET Core

My last post investigated ways to build a .NET Core desktop/console app with a web-rendered UI without bringing in the full weight of Electron. This seems to have interested a lot of people, so I decided to upgrade it to newer technologies and add cross-platform support.

The result is a little NuGet package called WebWindow that you can add to any .NET Core console app. It can open a native OS window (Windows/Mac/Linux) containing web-based UI, without your app having to bundle either Node or Chromium.

I’ve also decoupled it from Blazor. You can now host any kind of web UI inside the window. The repo contains a sample that uses Vue.js, and another that uses Blazor.

Link: https://blog.stevensanderson.com/2019/11/18/2019-11-18-webwindow-a-cross-platform-webview-for-dotnet-core/

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Introducing Orleans 3.0

We are excited to announce the Orleans 3.0 release. A great number of improvements and fixes went in, as well as several new features, since Orleans 2.0. These changes were driven by the experience of many people running Orleans-based applications in production in a wide range of scenarios and environments, and by the ingenuity and passion of the global Orleans community that always strives to make the codebase better, faster, and more flexible. A BIG Thank You to all who contributed to this release in various ways!

I was happy to see the generic host for co-hosting with something like ASP.NET Core. I’ve blogged Co-Hosting Orleans and ASP.NET Core which this about this feature.

Link: https://devblogs.microsoft.com/dotnet/orleans-3-0/

Snitch

A tool that helps you find transitive package references that can be removed.

> snitch Foo.csproj --tfm net462

Building Foo (net462)...

Building Bar (netstandard2.0)...

Building Baz (netstandard2.0)...

The following packages can be removed:

Autofac (ref by Baz)

Newtonsoft.Json (ref by Bar)

The following packages might be removed:

Castle.Core (ref by Baz) 4.4.0 <- 4.3.1 (Baz)

Link: https://github.com/spectresystems/snitch

What’s Your Problem? – Asbjørn Ulsberg

A talk given by Asbjørn Ulsberg from PayEx at the 2019 Platform Summit in Stockholm.

An API isn’t stronger than its weakest link and what’s often ignored in the ongoing maintenance and development of an API is the constant effort required to provide great self-servicable error messages. What this means is that without great, user-friendly error messages, your API is not going to be great.

Just think about your first interaction with an API. How many failing requests have you sent before you have dug yourself through swathes of error messages and documentation to get to that one penultimate successful request making your heart sing and fists shaking in the air?

Great error messages make them not feel like errors, but like friendly guidance towards a working request. They should be detailed enough to let the developer fix whatever problem there is themselves, like a dialogue between a customer and a support technician.

This talk will give you ideas of how to handle errors and exceptions that occur in your application, be it with the incoming request, database failures or errors received from a 3rd party and how to serialize them into user friendly and actionable problem messages.

Link: https://www.youtube.com/watch?v=ZWIUn5BHDBc

The next 5 years of ASP.NET Core – Ryan Nowak

Join Ryan Nowak on a tour of ASP.NET Core’s evolution from “Project K” to present day and look forward to a few possible futures. We’ll discuss technical design details of how the ASP.NET Core stack is changing from bottom (hosting and startup), through the server, middleware pipeline, and up to high-level frameworks like MVC and Blazor.

This is a technical deep-dive talk, and will explore possible design directions of .NET 5 and future releases.

Link: https://www.youtube.com/watch?v=7dJBmV_psW0

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Avoiding the Repository Pattern with an ORM

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pitfalls that I’ve seen.

To clarify, since this topic seems to really fire people up, I’m not saying that you shouldn’t use the repository pattern. I’m going to clarify why I don’t think under certain situations it’s very useful and other situations that I do find it useful.

This post was spurred on by a blog post and tweet:

IQueryable

The first thing I’ve seen with a repository is exposing IQueryable<T> (or DbSet<T>) from the underlying DbContext in your repository. This serves no purpose. It’s not abstracting anything at all.

What’s even worst is the consumers/callers don’t necessarily know at what point will they actually be retrieving data (doing I/O), unless you’re aware that the underlying IQueryable is coming from Entity Framework., Now when you call a method that materializes your query and actually hits the database (such as ToListAsync()).

Lazy Loading

Second, to this point is now if you have any type of navigation properties and are accessing IQueryable<T> from repository consumers, you must either eager load (via Include()) or have your consumers do the Include() or not realize all navigation properties are lazy loading.

Again, consumers are now aware of the underlying implementation that is Entity Framework.

IEnumerable

To overcome these issues, usually what comes next is avoiding the IQueryable<T> by returning an IEnumerable<T>.

The issue now is since you’re taking away control from the consumer, you must decide what data to Include() and Select() behind query methods.

What this often turns into is a pile of methods with various filtering parameters that could have been much easier expressed via a LINQ expression against the DbSet directly.

Query Objects

So if I don’t generally use the repository pattern, what do I use? Query Objects.

For querying, I’d rather have specialized objects that can return very specific data for the given use case. When implementing in vertical feature slices, as opposed to layers, each query is responsible for how it retrieves data.

The simplest solution is to use the DbContext and query directly.

The primary benefit is query objects only have dependencies that they actually require. Because each query object defines its own dependencies, you can change those dependencies without affecting other query objects.

A simple example of this is if you wanted to migrate from Entity Framework 6 to Entity Framework Core. You could migrate one query object at a time to EF Core instead of having to change over an entire repository that is highly coupled.

Testing

I can see the argument for using a repository because testing was difficult with EF6. However, with EF Core using the SQLite or the InMemory Provider, testing is incredibly easy.

I’ve written a post on how to use the SQLite provider with an in-memory database.

Testing a Query Object becomes incredibly easy without the need to mock.

Caching

Another argument for using the repository pattern is being able to swap out the implementation for a “cached repository”. I do use this pattern but in very select cases. Most times this is across bounded context were cached or stale data is acceptable.

If you decide to swap out the implementation of your repository, which was previously always hitting the database (point of truth) and now is using a cache implementation, how does that affect the callers? How quickly is the data invalidated?

Data can be stale the moment you retrieve it from the database, however adding caching to your repository without your callers knowing it can have a big impact on behavior.

Aggregate Root

One place I do often use a repository is when accessing an aggregate (in DDD Terms). My repositories often only contain two methods, Get(id) and Save(aggregateRoot).

The reason I do use a repository in this situation is that my repository usually returns an object that encapsulates my EF data model. I want it to fetch the entire object model and construct the aggregate root. The aggregate root does not expose data but only behavior (methods) to change state.

Repository Pattern Related

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.