Debugging with Runscope

Recently I’ve been using a really great tool to debug some different issues I was having with a Mobile Services project I’ve been working on.  The specific scenario I had was that I was sending data up to my Mobile Service but it didn’t seem like what I thought I was sending was getting there.  In the past, when developers run into this problem they have turned to tools like Charles or Fiddler.  Today I’ll explain what those are and then introduce you to a new alternative called Runscope.  Just a quick note, I don’t work for Runscope, they aren’t paying me, I don’t have stock in them, they aren’t run by my father’s brother’s nephew’s cousin’s former roommate or anything like that.  They just make a good product.

Hi Charles, I’m Fiddler

Charles and Fiddler are both program you run on your local computer (Charles is cross-plat while Fiddler is Windows only AFAIK).  Both of these programs function as a sort of proxy where all of your web traffic is routed through the application (Charles or Fiddler).  You can then get some really great information about what is going across the wire and what is coming back.  You can even get this to work for HTTPS traffic though not without a bit of a headache (or a lot depending on how you look at it for Android and iOS testing).  If you’re doing a lot of mobile development, one of the biggest issues with using Charles or Fiddler is that you can’t really use it if you’re testing something on a device.  Sure, you could share Wi-Fi from your network connected computer and then connect from the device to the computer and….ok that sounds absolutely terrible.  Thankfully, today I’m going to tell you about a tool that let’s you forget all about these HTTPS and “only on my computer” problems: Runscope.

Runscope

Runscope is a web based application that acts similar to a proxy but is much more powerful than just something that that.  At it’s most simplest, you set up a bucket which corresponds to a specific URL (the URL of your server side component).  Runscope then gives you a custom URL to their API.  In your application, you make your requests to Runscope’s custom URL.  Runscope then passes that request through to your server side component and then returns to your application whatever response they get back from your server.  That’s all the work you have to do to get started with Runscope.  From there, you just log in to your account and you can see all of the request and response details for everything that goes through Runscope.  It doesn’t matter if you’re making your request from a normal computer, a browser, a mobile application, an arduino, or anything else.  Since HTTPS works out of the box, there is no special configuration you need to do on a mobile device or certificates you need to install.  I know, that sounds crazy simple.  Let’s go ahead and walk through setting this up. 

Setting up a Bucket

To get started, the first thing you’ll want to do is go to http://www.runscope.com.  From there, you should see a Sign Up button near the top right.  Here you’ll be asked for your name, company or organization, email address, and password.  You’ll automatically be signed up for a trial of the Team Plan once you click Create Account (we’ll talk more about the different plans later).  You’ll next be treated to a little walkthrough of how things work.   The second step in the walkthrough actually allows you to pick a endpoint and then see a sample request and response against them.  After trying it out, you’ll also be shown some of the things you can do after you’ve tracked a request/response including editing and retrying, sharing with other people, retrying, and comparing.  Lastly we land at our dashboard.  Here we can add a new bucket by clicking the Add Bucket link in the bottom left.  For today’s example, I’m going to demonstrate using Runscope to track requests made to a Mobile Service I have.  If you haven’t checked out Mobile Services before, I’d highly recommend doing so.  In short, Mobile Services is a backend-as-a-service powered by Windows Azure with client SDKs for Android, iOS, .NET, and HTML/JS.  One of the things Mobile Services does is expose REST APIs for any data tables you create.  We’ll look at this today by using the quick start application for Mobile Services.  For today, I’ve created a new Mobile Service named RunscopeTest.  I’ve also downloaded the quick start for that Mobile Service for iOS.  If you’re testing with Mobile Services, you could easily do the same with any of the supported platforms.

Once I’ve created my Mobile Service, I can see that the URL for it is https://runscopetest.azure-mobile.net/.  Let’s go back to the Runscope portal and click the Add Bucket line.  We then name our bucket (I’ll use RunscopeTest here as well).  At the next screen, I’m told how to make requests and given the ability to enter my service’s URL:

Changing the client

After I enter my service’s URL, I’m given the corresponding Runscope URL.  Additionally, I’m able to see several examples of how I can use that URL in different languages.  I’m going to go ahead and copy that URL and in my Mobile Service client, I’m going to replace the Mobile Service URL with the Runscope URL.  No matter which client you’re using, you’ll find the Mobile Service URL wherever you are instantiating or setting up your MobileServiceClient (or MSClient for iOS).  Absolutely nothing else has to change in my client.  If you were accessing your own Web API or service layer, the steps would be the exact same on the client side.  You just use your own URL when you create your bucket.

Inspecting the request and response

Now we’re ready to see Runscope in action.  In my case, I’m going to load up the iOS app (which is a simple todo list).  When you run the Mobile Service’s quick start app, the first thing it does is send a request to your service to pull down any existing todo items (which aren’t completed).  As soon as you do that, you’ll see a new request appear in the Runscope portal:

Clicking on that link shows us our first request and response:

Clicking on that, we first see the response.  Clicking View Request shows all of the headers and querystring information for our request:

Of importance in the above two images are that we can see:

• the full URL we are making the request to.
• the request type (GET)
• that gzip is enabled
• that the user agent has been set to ZUMO/1.0 (this is set by the Mobile Services SDK)
• the Zumo Application Key
• the Zumo Installation ID
• the Zumo version
• the query string parameters (complete eq false)

If we go back to viewing the response, we see the response body was just an empty JSON array:

If we go ahead and insert a new item, we can see that our new request is a POST and contains a body:

Now if we hop over and look at the response to this:

We can see that after we post the item, we get the item back with a new id property that was generated on the server side of our Mobile Service.  That’s all there is to being able to see all of our requests and responses that are going across the wire with only changing the one URL on the client side!

Secuity

In the above example, by changing one URL, I’m able to see all of the requests made by my application and all of the responses they receive.  This is powerful stuff.  It’s even more powerful because this is still using HTTPS.  I didn’t have to tell my application to ignore invalid SSL certs or anything like that.  That means that if I didn’t know it was happening and didn’t bother checking to see where traffic from my device was heading, I might not even know I was going through Runscope.  If you’re sending super sensitive information across the wire, even if it is HTTPS, this is one thing to be cautious about.  Runscope has a full page talking about security practices, both on their side and on your side as a developer.  Runscope themselves use HTTPS on their whole site and ensure that each user in an organization has their own unique username and password and that only those people granted access can see your data.  Runscope recommends that you rely on HTTPS as well (if you’re not using HTTPS to talk to your server layer, it doesn’t really matter if something like Runscope is in the middle, everything you send is unsecured). 

Pricing

As I mentioned above, when you create a new account, you’re automatically signed up for a 30 day trial of their Team plan.  There are three separate plans they have including Free, Starter, and Team.  The plan your own dictates the number of requests you can make per month, the number of buckets you can have, the number of team members you can have with user accounts, and the service regions Runscope will work in.  The free plan allows you to have 3 separate buckets and process 2500 requests per month.  This is really great and is more than enough for my occasional usage for debugging purposes.  You can read more about their plans and pricing here.

More information

I would highly recommend checking out the Runscope website and actually taking it for a free spin.  You can also listen to Herding Code episode 168 where John Sheehan of Runscope talks about the service and where it’s going.  Also, you can see me using Runscope to debug an issue live (at the time) in this video from TechEd NA 2013.  It’s towards the end of the video where I’m using it.  In this situation I was sending over an incorrect variable name and Runscope helped me figure that out.

Let me know if using Runscope helps you out!