UPDATE: Oh dear James <shakeshead/>. So it seems someone was paying attention to my post and noticed my benchmarks were hideously flawed. I have removed them because I don't like looking like a total fool but I will be replacing the with honest, real and unstupified results as soon as I can. Apologies for any distress this may have caused. FUD is a powerful thing in the wrong hands but ignorance is worse.
I've been doing a bit of research into micro web frameworks in the.NET world recently and I was posed a question by a colleague.
Whats the point of a micro web framework?
I gave the usual response - more lightweight, smaller foot print blah blah blah. To be honest I was barely convincing myself. I suspected I had fallen into the trap of latching on to something because it was novel to me rather than any real reason. I am not saying they don't have a place in solutions technology stack, quite the opposite in fact, what I am saying is that I didn't have sufficient justification for bothering with them.
So I've spent a bit more time looking at the background of these microframeworks rather than the techs themselves and hopefully the next time someone asks I can give a more convincing reply.
What Is A Micro Web Framework
Pretty much a micro web framework is a framework that provides the absolute minimum feature set required to create a web application. Extra features can be added via extensions etc. but the sole purpose of a microframework is to allow the app to handle requests to certain URLs (routing) with a bit of basic error handling for 404's etc. (possibly). No feature creep, no bloated deployments just ultra-lean request/response handling.
The most famous microframework, and the one that started it all, comes from the Ruby world - Sinatra and it's "Hello World" example really highlights the ease of creating an app.
require 'sinatra'
get '/hi' do
"Hello World!"
end
Run this and navigate to /hi to see the amazing response of Hello World.
Micro Web Frameworks in the .NET World
So how does this compare to similar technologies in the .NET world. Most .NET solutions take a lot of inspiration from Sinatra (and why not it's pretty much the blueprints for the microframeworks) and this one is written using Jessica.
public class MyModule : Jessica.JessModule
{
public MyModule()
{
Get("/hi", p => "Hello, world!");
}
}
OK so there is a bit of extra language noise but this is to be expected when moving from Ruby to C# but it's just as readable. Jessica isn't the only microframework in the .NET world but it does seem to be one of the better ones (based on a very superficial amount of research - no offence meant to other frameworks - happy to be proven wrong). The other frameworks considered "micro" include,
What Makes Micro Frameworks Worthwhile?
So lets expand on my original argument of "more lightweight, smaller foot print blah blah blah". The most obvious is that a microframework by design is going to be a lot more lightweight than a normal framework. It's lifecycle for a request is going to be greatly simplified and ultimately this should help increase performance per request (I currently have no figures to back this up yet but I am working on it). As well as performance and increased throughput this lightweight approach should greatly reduce the memory footprint which will help your app scale a bit better1.
Another reason to consider a microframework is that you are in control of everything and that is good in my book. It's one of my arguments for choosing MVC over WebForms. No unnecessary injection of client side code or script managers or any of that sort of thing. No overly complex view properties being populated for no reason. Nothing but the stuff you put in.
Not exactly within the bounds of a microframework by definition but still worth mentioning is hosting. Nancy has a number of hosting options
- Standalone
- In a web app
- In a WCF Service
This sort of swappable hosting greatly increases portability of your app. Now this is Nancy specific but the effort required to create this sort of functionality with another microframework is trivial in comparison to the what it would be in MVC or WebForms.
Also many of the microframeworks have some sort of support for OWIN which is essentially a web abstraction that would allow your app to run on any OWIN supported server3. This sort of support would take longer to roll out across the larger frameworks which generally stick to IIS. I'm not saying it won't happen but the bigger your framework the slower change is going to happen.
That brings me to my final point - evolution. ASP.NET MVC has evolved very fast since v1.0 and there is no sign of that progress abating any time soon. Still it's speed is hindered by it's size. These microframeworks introduce new features (some experimental for the brave among us) much faster because of the fact they are small. Extending these frameworks don't require the creation of numerous classes to do simple things - there is generally a common extension point with a very small set of requirements.
Conclusion
I hope this has helped my colleagues get a better picture of why I think microframeworks are worthy of our time and why I am keen to do a bit of research on them. I also hope this has broadened a few minds in terms of solution architectures in the .NET world. Not everything needs to be some configurable, Enterprise ready, heavyweight application sometimes the simplest solution is all you need.
1 Provided you don't do something stupid!
2 As a friend pointed out it's easy to write a fast Hello World server so take these results with a healthy does of skepticism
3 It's early days for OWIN but still worth mentioning.