October 25, 2024

Has Ruby-on-Rails-Style 'Gem Glue-Gunning' Come to .NET?

In this post we’re going to travel back in time to 2010 - a happier, simpler time for early-stage startup software developers. When Heroku was free and front-end developers hadn’t had a chance to ruin the JavaScript ecosystem yet. We will eventually make our way back to 2024 .NET-land.

Ruby Land: 2010-2014

Back in the MarkedUp and early Petabridge days, I worked out of Coloft in Santa Monica, CA - a pioneer in the co-working space in Los Angeles. We had lots of startups and software developers of every shade working out of the space - it was even Uber’s original LA office location until they outgrew it.

But one group of developers who left a lasting impression on me was a Ruby on Rails consulting shop that specialized in delivering SaaS and mobile back-ends for Apple’s fledgling App Store (back in 2010.)

What these guys had down was a one-size-fits-all universal template for delivering client applications:

The founder and head developer of this company was some of my inspiration for the “Pet Technologist” in “Taxonomy of Terrible Programmers.” He was a decent guy but it didn’t seem to matter to him what his clients’ requirements were - the technology stack was essentially identical for every project.

At one point his team was implementing a social network on top of MongoDb using document references - and I asked him “wouldn’t it be easier to model relationships using a relational database?” His answer was along the lines of “but then we’d have to change the template.”

Eventually I understood - what made this system so productive was the magic of everything “just working.” The ORM, the queueing, the Redis and Mongo add-ons on Heroku, etc. But the team lead didn’t fundamentally understand how the magic worked and if this carefully glue-gunned stack of Ruby gems was disrupted somehow, the spell might break and he’d have a real problem on his hands. Don’t mess with the combination of gems.

.NET Land: 2024

I’m in the midst of shipping my first real piece of ASP.NET Core-powered SaaS that I’ve personally written since MarkedUp, which shut down in November, 2014 - approximately 10 years ago.

It’s been interesting experiencing what all has changed throughout the entire .NET / web front-end ecosystem - some things, like Razor, are more or less the same. But others, like the sophistication of ASP.NET Core’s routing system, are a sea-change from what they were 10 years ago.

But then there’s the meta of how developers do programming in .NET - in 2012-2014 when we were working on MarkedUp, the .NET ecosystem was an absolute mess. NuGet had been around for a few years, but there wasn’t a lot of great stuff on it. Now, in 2024, NuGet is teeming with lots of packages.

NuGet’s offerings run the gamut from fairly beefy frameworks all the way down to npm-style micro-packages (i.e. left-pad) such as OneOf.

This trend, in particular, raised my eyebrow - the use of fairly large packages for very acute problems. OneOf, FluentResults, FluentValidation, StronglyTypedId and others. These are all fairly popular packages with millions of downloads a piece.

Then you have some mid-grade packages (in terms of the complexity of the work being done) such as MediatR and AutoMapper (we’ll call this the “Bogard Stack”.)

It’s great that there’s a diversity of choice and a bunch of well-maintained packages available - this is objectively a good thing.

Formula-Driven Templates for .NET

But what I find really interesting is the formalization of combinations of these libraries into templates all with a similar connections and integrations - here’s some of the very frequently used “clean code” templates that leverage the Bogard Stack, Fluent Validation, and others:

All of these templates have over 10,000 stars on GitHub as of writing this - which is a lot for any .NET project. These templates have the same sort of formulations the aforementioned Rails ones did too - specific architecture AND infrastructure recommendations. They’re not merely design guides, in other words - much more opinionated and therefore shovel-ready.

But merely the presence of some popular ASP.NET Core templates really isn’t enough on its own - what’s even more interesting are some of the discussions about where these packages get used.

Does This Need to be a Package?

I just finished putting together a video about the “Results pattern” and that should go live on Petabridge’s YouTube channel in the next day or so - one of the things that prompted me to make that entire video was this /r/dotnet thread and this particular comment on it:

/r/dotnet user naming all of the libraries they tried to use to implement the Results pattern

Not to spoil my video, but the results “pattern” is trivial - it’s a record with a enum StatusCode, a human-readable string, and an optional return value. Anything more complicated than that and you’re probably doing it wrong. This user tried 2 different external libraries and a home-rolled solution and decided that the pattern is the problem? And that the solution to this is that we need a first party implementation built into the C# language or the base class libraries? Good lord.

There are hundreds of uninspiring comments like this on /r/dotnet every week - “[basic programming problem a middle schooler could solve] is too hard; library or language feature needed.” Hell, I wrote an entire post earlier this year on idiot .NET developers begging Microsoft to eliminate dozens of healthy, viable projects in the event-driven programming space just so they wouldn’t have to bother evaluating them.

This is what makes me think .NET has entered its own Ruby Gem Glue-Gunning era - “just give me the clean code ASP.NET boilerplate template with the auto-mapping-validation thingy and the magic entity framework commands that do the thing.”

Is Glue Gunning Bad?

Do I think glue-gunning is a bad thing - if it’s even really happening en masse in the .NET ecosystem? No, not really. I’m a businessman first, technologist second. Getting product out the door rules the roost around here. But that being said, you don’t get to be mad when other developers notice:

Use whatever you want and hopefully it saves you time and trouble, but if it’s important, be sure to learn what its limitations and best uses are. Make templates, use formulas, be productive, but make damn sure you understand what they do before you bet your bottom line on them.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..