Saturday, November 16, 2013

IamA Microsoft ASP.NET and Web Tools Team (and Azure) on reddit

Yesterday, Scott Hanselman, Damian Edwards and  Mads Kristensen from Microsoft were at Reddit answering people's questions and future of lot of things around web/cloud development and Microsoft. The transcript was quite informative and interesting to read. If you are a web developer using any of Microsoft's technologies or are apssionate about cloud, I highly recommend following the transcript here - AMA

I am yet to go through the whole transcript but here are some of the exciting bits I got to know about from the chat

  1. They talked about how the OSS initiative started at Microsoft. How Phil Haack and ScootGu played an important role and where the OSS initiative is headed. It was interesting to know that guys have managed to open source a lot of things in last couple of years. It was also nice to know that they promote external open source .NET based web frameworks like Nanacy, ServiceStack and Oak etc.
  2. Katana  project is getting serious attention. Do not be surprised if one day ASP.NET MVC works completely off Katana without any dependency on System.Web. If you have no clue what I am talking about - System.Web is part of BCL and is not open sourced. Where as, ASP.NET MVC is open sourced. MVC takes dependency on System.Web as of now which is a problem because their release cycles are not synchronised and MVC team cannot add new features to System.Web.If you are interested, the roadmap for Katana project is here 
  3. Rewriting project file structure - Microsoft is listening to people's complaints about pains of XML based project file. They are working on building a new project file formats that enable more collaboration with less conflicts after committing project files. It is not clear when this would be released.
  4. Offline NuGet - Again, they are listening. They are working on ideas to make NuGet available offline. Again, no news on when this would be available but effort is going on.
  5. Folks at Microsoft have interest in seeing remote debugging in browsers initiative. Visit their website to know more about the initiative. It would be a good boost of web developer's productivity if this initiative sees the light of the day.
  6. BrowserLink and Side-Waffle project - There are lot of interesting things happening around BrowserLink and Side-Waffle project. Take a look at Side-Waffle's github page
  7. SASS and LESS support in visual Studio - VS2013 has SAAS editor to make the lives of graphic designers among us easy. And they are actively working on a LESS editor for upcoming release.
  8. TypeScript - TypeScript team is working on visual studio tooling for TypeScript from ground up. This is in order to offer a richer experience. They are hoping to release TypeScript 1.0 and tooling support in Visual Studio together
  9. ASP.NET Web Pages - Mind you, this is not Web Forms. I did not know this existed. Take a look here - Web Pages
  10. What's happening in the world of Visual Studio
  11. Microsoft's Partnership with Xamarin and what's in future around building cross-platform mobile apps in C#
Besides the above they talk a lot about future of EF, MVC and SignalR in general, what helped them reach where they are, life at Microsoft and lot of other things. The transcript is worth reading. Here is the link again -

Wednesday, November 6, 2013

Why Sprint.Rest client is better than RestSharp for building REST clients?

If you are interacting with any REST service then you problably have used some kind of HTTP client library. I have used RestSharp on few project. RestSharp is quite cool. You can learn more aobut RestSharp from their website. They have got an example there that talks about what you can do with Restsharp. If you have never used a library for interacting with REST services then I strongly recommend taking a look at RestSharp.

But this post is not about Restsharp. Don't get me wrong, ReshSharp is a cool and sleep library and delivers exactly what is says on the tin. There is one area though where it dis-appointed me - testability. When you are writing client code to communicate with a REST service and if you are like me, you would like that code to be unit tested. With Restsharp there is no way of mocking the actual call (or at least I did not find anything either in source code or in their documentation). Having to make real calls from the tests is a heavy affair that I would like to avoid. And I also do not want to bombard the real service with loads of requests that my client code needs to be tested for. So I was on lookout for a new REST client library. My search lead me to REST client that is part of Spring framework (not the Java one but the one built for .NET). I was amazed by the features that this library offers and immense documentation that they have got. You can find more details on their website. The part I most liked was ability to mock the service, set expectations on requests sent and return mocked responses. Let's dive into some code


One of the common tests that I write for my client is to ensure that request is being made on correct url. In case of a POST request, I also like to ensure that correct post body is being sent to server. Take a look at following test code

public void SendsRquestOnCorrectUrl()
    var restTemplate = new RestTemplate("baseAddress");

    var document = new Document("master");

    var mockRestServer = MockRestServiceServer.CreateServer(restTemplate);
                    .AndExpect(RequestMatchers.MatchUri(string.Format("{0}/api/document", ApiBaseUrl)))

    restClient.PostForMessage("api/document", document);

So you create an instance of RestTemplate, which is your client making HTTP connections to server. You then create an instance of mock server by calling MockRestServiceServer.CreateServer and passing in previously created instance of RestTemplate. This would now start intercepting all the calls we make using the restTemplate. Next, you set some expectations on mockRestServer. I have set following three expectations here

  1. It should expect a new request
  2. It should expect the URI on which the request would be made to match "ApiBaseUrl/api/document"
  3. It should expect the request body to contain the JSON version of document object
Then post the document object using PostForMessage method. In the end, assert the set expectations by calling Verify() method on MockRestServiceServer.

The best part is RequestMatchers class. This come bundled with loads of various matching options that you would not have to go looking for help on internet.

And more

As I used Spring Rest client more and more, I figured out there more good things about it besides testability.

  1. Less plumbing code - On most occasions, you would end up writing lesser plumbing code as compared to RestSharp.
  2. HTTP Message Conversion - Library comes packaged with several message converters that can automatically convert response data from byte array, ATOM/RSS feeds, files, strings, JSON, sliverlight etc. And if you are working with a custom response format, it is not very difficult to build and plug your own message converter. 
  3. Authentication - Besides supporting basic authentication, it support OAuth
  4. Request interceptor - This should not be confused with mocking described above. Interceptors let you inject code at various points of request life-cycle. For example, you can start a timer just before a request is sent and stop it right after response is received and calculate the response time of the server. You can implement different interceptors for different purposes.
  5. Asynch story - They have got async implementation using Task Parallel Library (TPL)
  6. and lot of other features

So far I am quite happy with this library. I have not seen many people using it so it would nice to know what you think of this library.