ASP.NET Web API <#= Proxy to T4 #>

One of the coolest new features of ASP.NET is Web API, which allows you to build powerful RESTful services exposed over HTTP. HTTP is not just for serving up web pages, but it provides a platform for building APIs that expose services and data. It is simple, flexible, and ubiquitous.

ASP.NET Web API is all about REST HTTP Services. Unlike Web Services, it does not expose an end-point for meta-data exchange. When consuming a HTTP Service, you will have to create your own client-side code that must serve as a proxy for interfacing with the API.

Like any other WCF junkie out there, I've been working with Windows Communication Foundation for quite some time now implementing Web Services. Not only is it flexible and extensible, but it offers inter-operability, multiple message patterns, transactions and  meta-data exchange etc.

The nice thing about WCF is meta-data exchange, which allows you to generate the client-side proxy-code, contracts and classes used for talking to the service. On the other hand, ASP.NET Web API is more light-weight, operates only via HTTP and is used more for serving CRUD-based operations. The latter, however, does not have functionality (yet) for exposing service meta-data. Until now...

Some API "best suggestions"

In today’s modern world of computing it’s a no-brainer to expose some kind of service for the outside world to access your enterprise platform in a controlled fashion. Because of good old legacy systems, we all know that “the perfect world” never exists in any of our clients’ current environment. There are always compatibility issues regarding unified communication between these systems and we end up building all kinds of middle layers to facilitate this interaction. The latter makes it a nightmare to implement any kind of external service.

By building a platform with a collection of loosely coupled components and exposing specific functionality via an unified interface is much better than having all kinds of silo systems talking to each other. We can achieve this by implementing an API over REST (Representational state transfer).

Laying it out: Onion Architecture

It's a fact, there is no Single Silver Bullet for every solution, but we can come damn close. Having the right architecture sets a solid foundation for any solution. When I say "architecture", I mean structuring the solution in a specific strategic way; with the aim to have the components (or layers) loosely coupled and tightly cohesive to the maximum extent possible keeping in mind the feasibility of the trade-off.

KnockedUp: Customizing the use of KnockoutJs

I blogged previously about a nifty little library called KnockoutJs.

To bring you up to speed, here is a typical example on the original usage of KnockoutJs:

Note that you have to specify all your bindings for an element in the data-bind attribute.

This got me thinking...

Doing all these bindings in one attribute may become untidy and unreadable. On the HTML, I wanted a way to explicitly define my bindings as attributes on a specific element.

...then KnockedUp was born

I created a library (dependent on JQuery & KnockoutJs) that gives you the same result as KnockoutJs and called it KnockedUp :) .

SignalR: Build real-time, multi-user interactive web apps

Some History

A while back I was involved in developing an online-bidding app. This may not sound too exciting nor complicated, but because this kind of application was web-based, it introduced a whole new set of challenges.

One of the core requirements of this app was to be critically up-to-date with real-time results. As a user bids on something, the action needs to be broadcast to the rest of the players bidding. The main challenge was achieving this on the web.