tl;dr: FubuMVC stressed concise code and conventions over writing explicit code and that turns out to be polarizing

The typical way to be successful in OSS is to promote the hell out of your work before you give up on it, but I’m under a lot less pressure after giving up on FubuMVC and I feel like blogging again.  Over the next couple months I’m going to write about the technical approach we took on FubuMVC to share the things I think went well, the stuff I regret, how I wish we’d done it instead, discarded plans for 2.0, and how I’d do things differently if I’m ever stupid enough to try this again on a different platform.

 

Some Sample Code

So let’s say that you start a new FubuMVC project and solution from scratch (a topic for another blog post) by running:

fubu new Demo --options spark

You’ll get this (largely placeholder) code for the MVC controller part of the main home page of your new application:

namespace Demo
{
        // You'd generally do *something* in this method, otherwise
        // it's just some junk code to make it easier for FubuMVC
        // to hang a Spark or Razor view off the "/" route
        // For 2.0, we wanted to introduce an optional convention
        // to use an "action less view" for the home page
	public class HomeEndpoint
	{
		public HomeModel Index(HomeModel model)
		{
			return model;
		}
	}
}

To make things a little more clear, fubu new also generates a matching Spark view called Home.spark to render a HomeModel resource:

<viewdata model="Demo.HomeModel" />

<content:header></content:header>

<content:main>
Your content would go here
</content:main>

<content:footer></content:footer>

The code above demonstrates a built in naming convention in FubuMVC 1.0+ such that the home “/” route will point to the action “HomeEndpoint.Index()” if that class and method exists in the main application assembly.

Some additional endpoints (FubuMVC’s analogue to Controller’s in MVC frameworks) might look like the following:

    public class NameInput
    {
        public string Name { get; set; }
    }

    public class Query
    {
        public int From { get; set; }
        public int To { get; set; }
    }

    public class Results { }

    public class MoreEndpoints
    {
        // GET: name/{Name}
        public string get_name_Name(NameInput input)
        {
            return "My name is " + input.Name;
        }

        // POST: query/{From}/to/{To}
        public Results post_query_From_to_To(Query query)
        {
            return new Results();
        }
    }

 

What you’re not seeing in the code above:

• No reference whatsoever to the FubuMVC.Core namespace.
• No model binding invocation
• No code to render views, write output, set HTTP headers
• No code for authentication, authorization, or validation
• No “BaseController” or “ApiController” or “CoupleMyCodeVeryTightlyToTheFrameworkGuts” base class
• No attributes
• No marker interfaces
• No custom fluent interfaces that render your application code almost completely useless outside of the context of the web framework you’re using

What you are seeing in the code above:

• Concrete classes that are suffixed with “Endpoint” or “Endpoints.”  This is an out of the box naming convention in FubuMVC that marks these classes as being Action’s.
• Public methods that take in 0 or 1 inputs and return a single “resource” model (they can be void methods too).
• Route patterns are derived from the method names and properties of the input model — more on this in a later post because this one’s already too long.

 

One Model In, One Model Out and Automatic Content Negotiation

As a direct reaction to ASP.Net MVC, the overriding philosophy from the very beginning was to make the code we wrote be as clean and terse as possible with as little coupling from the application to the framework code as possible.  We also believed very strongly in object composition in contrast to most of the frameworks of the time that required inheritance models.

To meet this goal, our core design idea from the beginning was the one model in, one model out principle.  By and large, most endpoints should be built by declaring an input model of everything the action needs to perform its work and returning the resource or response model object.  The framework itself would do most of the repetitive work of reading the HTTP request and writing things out to the HTTP response for you so that you can concentrate on only the responsibilities that are really different between actions.

At runtime, FubuMVC is executing content negotiation (conneg) to read the declared inputs (see the NameModel class above and how it’s used) from the HTTP request with a typical combination of model binding or deserialization, calling the action methods with the right input, and then rendering the resource (like HomeModel in the HomeEndpoint.Index() method) again with content negotiation.  As of FubuMVC 1.0, rendering views are integrated into the normal content negotiation infrastructure (and that ladies and gentlemen, was a huge win for our internals).    Exactly what content negotiation can read and write is largely determined by OOTB conventions.  For example:

• If a method returns a string, then we write that string with the content-type of “text/plain”
• If an action method returns a resource model, we try to “attach” a view that renders that very resource model type
• In the absence of any other reader/writer policies, FubuMVC attaches Json and Xml support automatically with model binding for content-type=”application/x-www-form-urlencoded” requests

The automatic content negotiation conventions largely means that FubuMVC action methods just don’t have to be concerned about the details of how the response is going to be written out.

View resolution is done conventionally as well.  The easiest, simplest thing to do is to simply make your strongly typed Spark or Razor view render the resource model type (the return type) of an action method and FubuMVC will automatically apply that view to the matching action.  I definitely believe that this was an improvement over the ASP.Net MVC ViewResult mechanism and some other frameworks *cough* NancyFx *cough* adapted this idea after us.

The huge advantage of the one model in, one model out was that your action methods became very clean and completely decoupled from the framework.  The pattern was specifically designed to make unit testing action methods easy, and by and large I feel like we met that goal.  It’s also been possible to reuse FubuMVC endpoint code in contexts outside of a web request because there is no coupling to FubuMVC itself in most of the action methods, and I think that’s been a big win from time to time.  Try to do that with Web API, ASP.Net MVC, or a Sinatra-flavored framework like NancyFx!

The downside was the times when you really did need to exert more fine grained control over HTTP requests and responses.  While you could always happily take in constructor dependencies to read and write to the raw HTTP request/response, this wasn’t all that obvious.

 

The Russian Doll Behavioral Model

I’ve regretted the name “FubuMVC” almost from the beginning because we weren’t really a Model 2 MVC framework.  Our “Action” methods just perform some work within an HTTP request, but don’t really act as logical “Controller’s.”  It was also perfectly possible to build endpoints without Action methods and other endpoints that used multiple Action methods.

The core of FubuMVC’s runtime was the Russian Doll “Behavior” model I described way back in 2011 — in which action methods are called inside of a pre-built Behavior in the middle of a chain.  For example, our HomeEndpoint.Index() action above has a chain of nested behaviors in real life something like:

1. AuthenticationBehavior
2. InputBehavior — does content negotiation on the request to build the HomeModel input
3. ActionCall –> HomeEndpoint.Index() — executes the action method with the input read by conneg and stores the output resource for later
4. OutputBehavior — does conneg on the resource and “accepts” header to write the HTTP response accordingly

FubuMVC heavily uses additional Behavior’s for cross cutting concerns like authorization, validation, caching, and instrumentation that can be added into a chain of behavior to compose an HTTP pipeline.  Every web framework worth its salt has some kind of model like this, but FubuMVC took it farther by standardizing on a single abstraction for behaviors (everything is just a behavior) and exposing a model that allowed you to customize the chain of behaviors by either convention or explicitly on a single endpoint/route.

In my opinion, the Behavior model gave FubuMVC far more modularity, extensibility, and composability than our peers.  I would go so far as to say that this concept has been validated by the sheer number of other frameworks like Microsoft’s WebAPI that have adopted some form of this pattern.

 

Clean, terse “magical” code versus explicit code

The downside to the behavior model, and especially FubuMVC’s conventional construction of the nested Behaviors is the “magical” aspect.  Because the framework itself is doing so much more work for you, there isn’t a blob of explicit code in one place that tells a developer everything that’s happening in an HTTP request.  In retrospect, even though I personally wanna write the tightest, most concise code possible and avoid repetitive code, other developers are much happier writing and reading code that’s much more explicit — even when that requires them to write much more repetitive code.  It turns out that repetitive code ceremony is not a bad thing to a large number of developers. 

Other developers hated the way that FubuMVC doesn’t really do much to lead you to what to do next or make the framework capabilities discoverable because so much of the code was meant to be driven by FubuMVC conventions based on what your code looked like rather than you writing explicit code against FubuMVC API’s with Intellisense there to guide you along the way.  And yes, I’m fully cognizant that I just make an argument in favor of a Sinatra style fluent interface like NancyFx’s.  I know full well that many developers considered NancyFx much easier to learn than FubuMVC because of Nancy’s better discoverability.

We did offset the “magical” problem with diagnostics that I’ll discuss at a later time, but I think that the “magical” aspect of FubuMVC scared a lot of potential users away in retrospect.  If I had it to do over again, I think I would have pushed to standardize and describe our built in conventions much earlier than we did — but that’s another blog post altogether.

 

What I wanted to do in FubuMVC 2.0 

I had no intention of adopting a programming model more like Sinatra or Web API where you write more explicit code.  My feeling is that there is room in the world for more than one basic approach, so for 2.0, I wanted to double down on the “one model in, one model out” approach by extending more conventions for finer grained control over the HTTP request & response without losing the benefits.  Things like:

• More built in model binding conventions to attach Cookie values, system clock values, IPrincipal’s, and whatever else I could think of into the OOTB model binding.
• Built in conventions for writing header, response codes, and cookie values from resource model values to maintain the one model in, one model out motif while still allowing for more powerful HTTP API capabilities
• We did change the content negotiation defaults to make views “additive” to Json/Xml endpoints, so that any endpoint that renders a view for accept=”text/html” can also return Json or Xml by default
• We made it a little easier to replace the built in Json/Xml serialization
• We did streamline the content negotiation internals to make customization smoother
• Add new built in conventions to attach custom content negotiation readers and writers to the appropriate input and resource types

 

tl;dr:  I’m giving up on fubu and effectively retiring from OSS on .Net

 

Some things came to a head last week and I announced that I’m planning to cease work on FubuMVC after finishing some performance and startup time optimization work as a 2.0 release — which right now means that FubuMVC and its very large ecosystem of surrounding projects is effectively kaput.  Even just a couple weeks ago I was still excited for our 2.0 release and making big plans, but the writing has been on the wall for quite some time that FubuMVC no longer has enough community support to be viable and that the effort I think it would take to possibly change that situation probably isn’t worth it.

For me personally, FubuMVC has turned out to be a fantastic experience in my own learning and problem solving growth.  My current position is directly attributable to FubuMVC and I’ve generally enjoyed much of the technical work I’ve gotten to do over the past 2-3 years.  I’ve forged new relationships with the folks who I met through my work on FubuMVC.

On the downside, it’s also been a massive opportunity cost because of all the things I haven’t learned or done in the meantime because FubuMVC takes up so much of my time and that’s the main reason that it has to stop now.

Some History

 

Rewind to the summer of 2008.  I had just started a new job where we were going to do a big rewrite of my new company’s website application.  My little team had a choice in front of us, we could either choose Ruby on Rails (the hot thing of the day) or continue with .Net and use the brand new ASP.Net MVC framework coming down the pike.  If I had it all to do again, I would choose RoR in a heartbeat and just have gotten on with getting the project done.  At the time though, the team previous to us had completely flopped with RoR (not for technical reasons) and the company was understandably leery of using Rails again.  At the same time, this was at the tail end of the ALT.Net movement and I felt very optimistic about .Net at the time.  Plus, I had a large personal investment in StructureMap and Fluent NHibernate (yes Virginia, there was a time when we thought ORM’s were a good idea).

We opted for .Net and started working on early versions of ASP.Net MVC.  For various reasons, I disliked MVC almost immediately and started to envision a different way of expressing HTTP endpoints that wouldn’t require so much coupling to the framework, less cruft code, and better testability at the unit level.  For a little while we tried to work within ASP.Net MVC by customizing it very heavily to make it work the way we wanted, but MVC then and now isn’t a very modular codebase and we weren’t completely happy with the results.

From there, we got cocky and in December 2009 embarked on our own framework we called FubuMVC based on the “for us, by us” attitude because we believed that after all the bellyaching we did for years about how bad WebForms was (and it was) Microsoft gave us yet another heavily flawed framework with little input from the community that was inevitably going to be the standard in .Net.

Fast forward to today and FubuMVC is up to v1.3, spawned arguably a healthy ecosystem of extensions, and it’s used in several very large applications (fubu’s sweet spot was always larger applications).  It’s also failed miserably to attract or generate much usage or awareness in the greater .Net community — and after this long it’s time for me to admit that the gig is up.

 

Why I think it failed

Setting aside the very real question of whether or not OSS in .Net is a viable proposition (it’s largely not, no matter how hoarse Scott Hanselman makes himself trying to say otherwise), FubuMVC failed because we — and probably mostly me because I had the most visibility by far — did not do enough to market ourselves and build community through blog posts, documentation, and conference speaking.  At one time I think I went almost 2 years without writing any blog posts about fubu and I only gave 3-4 conference talks on FubuMVC total over the past 5 years.  I believe that if we’d just tried to get FubuMVC in front of many more people earlier and generated more interest we might have had enough community to do more, document more, and ground away the friction in FubuMVC faster through increased feedback.

We also didn’t focus hard enough on creating a good, frictionless getting started story to make FubuMVC approachable for newbies.  FubuMVC was largely written for and used on very large, multi-year projects, so it’s somewhat understandable that we didn’t focus a lot on a task that we ourselves only did once or twice a year, but that still killed off our growth as a community.  At this point, I feel good about our Rails-esque “fubu new” story now, but we didn’t have that in the early days and even now that freaks out most .Net developers who don’t believe anything is real until there’s a Visual Studio plugin.

I’ll leave a technical retrospective of what did and did not work well for a later time.

What I’m doing next

I turned 40 this January, but I feel like I’m a better developer than ever and I’m not really burnt out.  I tease my wife that she’s only happy when she’s planning something new for us, but I know that I’m happiest when I’ve got some kind of technical project going on the side that lets me scratch the creative itch.

I’d like to start blogging again because I used to enjoy it way back but I wouldn’t hold your breathe on that one.

We’re kicking the tires on Golang at work for server side development (I’m dubious about the productivity of the language, but the feedback cycle and performance is eye popping) and the entire Scala/TypeSafe stack.  I’m a little tempted to rewrite StructureMap in Scala as a learning experience (and because I think the existing Scala/Java IoC containers blow chunks).  Mostly though, Josh Arnold and I are talking about trying to rebuild Storyteller on a Node.js/Angular.js/Require.js/Mimosa.js/Bower stack so I can level up on my JavaScript skills because, you know, I’ve got a family to support and JavaScript quietly became the most important programming language on the planet all the sudden.

I’ll get around to blogging a strictly technical retrospective later.  Now that I’m not under any real pressure to deliver new code with fubu, I might just manage to blog about some of the technical highlights.  And if I can do it without coming off as pissed and bitter, I’ve got a draft on my thoughts about .Net and the .Net community in general that I’ll publish.

tl;dr:  FubuCsProjFile is a new library from the fubu community for manipulating Visual Studio.Net project files and a new composable templating engine.

The FubuMVC community was busy last year building all new functionality for build automation, documentation generation, and project templating.  What we haven’t done yet is actually talk about what we were doing in any kind of way that might make it possible for other folks to kick the tires on all that stuff.  This blog post and the heavily under construction website at http://fubuworld.com is an attempt to change that.

For a couple years we’ve had a couple one-off pieces of code to manipulate csproj files with raw Xml manipulation copied over some of our tooling.  When we started to get serious about rebuilding the “fubu new” functionality, we knew that we first needed a more serious way to add, query, remove, and modify items in .csproj files and .sln files.  I looked around for prior art, but found little besides the MSBuild libraries themselves which — shockingly! — did not work in Mono (wouldn’t even compile as I recall).  Fortunately, Monodevelop has very robust MSBuild manipulation code with all kinds of care taken to avoid unnecessary merge problems by maintaining line breaks and file formatting.  Because it has a permissive license, I mostly copied the csproj manipulation code out of Monodevelop and wrapped a little bit prettier object model around their very low level API.

On top of the csproj file manipulation, I added a hack-y class for adding and removing projects from Visual Studio.Net solution files and a from scratch templating engine we use heavily from our “fubu new” functionality.

We certainly don’t yet support every single thing you can do in a csproj file, but we’re already using FubuCsProjFile within Bottles to attach embedded resources, inside the forthcoming Ripple 3.0 release for querying and manipulating assembly references, and as part of the prototype functionality inside of the fubu.exe tool for generating Spark or Razor views.

FubuCsProjFile is available on Nuget under the permissive Apache 2.0 license.  We have received some reports that FubuCsProjFile has some unit tests that break on Mono (“\” instead of “/”, Unix vs. Windows line breaks, the normal stuff).  That’ll get resolved soon-ish, but that just means that I can’t claim that it will work flawlessly on Mono/*nix right now.