Except for having a bad, bad experience using EasyJet on the way towards Milan, UGIALT.NET was a blast! Here's the slide deck and sample code for my session on SignalR.

Abstract: "SignalR. Code, not toothpaste. (or: Using SignalR for realtime client/server communication) Today’s users are interested in a rich experience where the terms client and server don’t mean a thing. They expect real-time action between both, no matter if the technology used is HTML5 websockets or something else. This session will cover SignalR and show you how it can be used to communicate in real time between the client and server, using HTML5 or not. Combine SignalR with ASP.NET MVC, jQuery and perhaps a sprinkle of Windows Azure and you’ll have an interesting, reliable and fast stack to build your real-time client-server and server-client communications. Join me on this journey between web, cloud and user. No toothpaste. Just code."

Demo code is available for download as well: Demos.zip (1.68 mb)

PS: EasyJet was kind enough to provide us with a flight attendant that looked and talked like Borat on the flight back, which made me laugh numerous times during the flight. Is nice!

So you have an API. Congratulations! You should have one. But how do you track who uses it, what client software they use and so on? You may be logging API calls yourself. You may be relying on services like Apigee.com who make you pay (for a great service, though!). Being cheap, we thought about another approach for MyGet. We’re already using Google Analytics to track pageviews and so on, why not use Google Analytics for tracking API calls as well?

Meet GoogleAnalyticsTracker. It is a three-classes assembly which allows you to track requests from within C# to Google Analytics.

Go and  fork this thing and add out-of-the-box support for WCF Web API, Nancy or even “plain old” WCF or ASMX!

Using GoogleAnalyticsTracker

Using GoogleAnalyticsTracker in your projects is simple. Simply Install-Package GoogleAnalyticsTracker and be an API tracking bad-ass! There are two things required: a Google Analytics tracking ID (something in the form of UA-XXXXXXX-X) and the domain you wish to track, preferably the same domain as the one registered with Google Analytics.

After installing GoogleAnalyticsTracker into your project, you currently have two options to track your API calls: use the Tracker class or use the included ASP.NET MVC Action Filter.

Here’s a quick demo of using the Tracker class:

1 Tracker tracker = new Tracker("UA-XXXXXX-XX", "www.example.org");
2 tracker.TrackPageView("My API - Create", "api/create");

Unfortunately, this class has no notion of a web request. This means that if you want to track user agents and user languages, you’ll have to add some more code:

1 Tracker tracker = new Tracker("UA-XXXXXX-XX", "www.example.org");
2 
3 var request = HttpContext.Request;
4 tracker.Hostname = request.UserHostName;
5 tracker.UserAgent = request.UserAgent;
6 tracker.Language = request.UserLanguages != null ? string.Join(";", request.UserLanguages) : "";
7 
8 tracker.TrackPageView("My API - Create", "api/create");

Whaah! No worries though: there’s an extension method which does just that:

1 Tracker tracker = new Tracker("UA-XXXXXX-XX", "www.example.org");
2 tracker.TrackPageView(HttpContext, "My API - Create", "api/create");

The sad part is: this code quickly clutters all your action methods. No worries! There’s an ActionFilter for that!

1 [ActionTracking("UA-XXXXXX-XX", "www.example.org")]
2 public class ApiController
3     : Controller
4 {
5     public JsonResult Create()
6     {
7         return Json(true);
8     }
9 }

And what’s better: you can register it globally and optionally filter it to only track specific controllers and actions!

 1 public class MvcApplication : System.Web.HttpApplication
 2 {
 3     public static void RegisterGlobalFilters(GlobalFilterCollection filters)
 4     {
 5         filters.Add(new HandleErrorAttribute());
 6         filters.Add(new ActionTrackingAttribute(
 7             "UA-XXXXXX-XX", "www.example.org",
 8             action => action.ControllerDescriptor.ControllerName == "Api")
 9         );
10     }
11 }

And here’s what it could look like (we’re only tracking for the second day now…):

We even have stats about the versions of the NuGet Command Line used to access our API!

Enjoy! And fork this thing and add out-of-the-box support for WCF Web API, Nancy or even “plain old” WCF or ASMX!