Posted on by Jon

Herding Code 168: John Sheehan on Runscope

This week on Herding Code, the guys talk to John Sheehan about the recent launch of his new API developer tools company, Runscope.

Download / Listen:

Herding Code 168: John Sheehan on Runscope [audio://herdingcode.com/wp-content/uploads/HerdingCode-0168-Runscope.mp3]

Show Notes:

  • Intro
    • (00:30) "What is Runscope and why should I care?"
    • (00:55) Runscope is the ultimate API integrator developer’s toolbox. It helps you solve the problems you encounter in dealing with API’s from a consumption standpoint. It takes invisible API traffic and makes it visible, then helping you do all sorts of things with it: debugging, sharing, retry a request from the website, testing features like response playback without hitting the API, webhook debugging, etc. When you rely on an API, you’re not just taking on a service dependency – it’s code code that’s running on someone else’s service, and you should treat it like it’s code that’s under your control. You should apply the same testing rigor and should have the same debugging facilities.
    • (03:25) Jon asks about the launch. Anyone can try it out now at runscope.com. John talks about the internal preview (shoutout to Kevin Dente, the first beta tester) and the launch at GlueCon and press at TechCrunch and TheNextWeb.
  • (04:35) Overview of features:
    • Traffic Inspector
      • (04:55) In your code, instead of calling an API directly, you create a Runscope URL by including a Runscope bucket key and replacing dots with dashes. Essentially you’re pointing your API calls at Runscope, which then extracts the hostname and makes the API request for you. A lot of other tools require you to change your API calls by modifying your authentication, adding parameters, etc. Runscope doesn’t require any changes outside of the hostname, and all of your original headers and request parameters stay intact. This means you can just flip it on by changing your hostname and turn it off when done. You can then view all your requests in the Runscope website, filter to only show errors, All your requests show up in
      • (07:45) Scott says this is essentially a reverse proxy. John agrees that’s technically correct, but they avoid the term because they’re doing a lot more.
      • (08:13) Scott asks if Runscope adds headers to allow filtering or other things. John says the only modification they make is to add a Runscope message id header to allow lookup. They’re thinking of some things in the future like caching credentials to apply to a lot of requests and other features that benefit performance, security, etc.
      • (09:27) Jon asks about the security concerns, as Runscope is kind of like a man in the middle. John says they’re very concerned with security, and points to https://www.runscope.com/docs/security for a lot more information about their security practices. They’re looking at future things like encrypted storage, and currently if you make an SSL request to Runscope they will forward it over SSL to the API provider.
      • (11:45) Jon asks about cases like multi-legged auth. John says everything just flows through Runscope, with one exception – if a response comes back with a location header then Runscope will modify the location to a Runscope url so if the client follows it it’ll be captured.
      • (12:40) Scott asks about how geolocation works, since Runscope is making the request from a different location. John says that currently they’re making requests from US East Coast, but in the future they want to allow requests from specific geographic areas.
      • (14:10) Scott asks about a current app he’s working on which requires a custom certificate to connect to an API and asks if that would be supported. John says that they’re looking at both support for custom certificates as well as on -premises installations to support those scenarios.
      • (15:35) Scott asks about support for non-standard ports. John says they support that using a Runscope request port header.
    • Request Editor
      • (16:09) Jon asks about the Request Editor. John explains that they really wanted to make it possible to edit and create requests as easily as any other code. Their original inspiration was the hurl.it site. Jon interjects that he loves using hurl.it to see where shortened or dodgy urls will take him before clicking on them. John says they’ve taken the idea of hurl.it and really filled it out to include storage, advanced editing, etc. They also built in some helpers for basic auth, digest authentication, OAuth 1, OAuth 2 token generators, etc.
      • (19:45) Scott asks if they’ve looked at integrating OWASP tests to run some automated security inspection for things like SQL injection, XSS, redirect attacks, etc. John says he’d like to let people create collections and share them with others.
    • Shared Requests
      • (21:11) Jon says that when he was testing during the beta and hit a question, John just had him share the request with him. John says that he really wanted that feature when he was at Twilio, and they currently use it all the time internally.
      • (22:39) Jon asks if there’s a way to download or otherwise privately share a request. John says the best way to do that now is use team account, which allows for privately share requests within the team. They’re also looking at allowing redacting some fields in shared requests, so you can share a request without revealing your password or other sensitive information.
    • Passageway
      • (22:48) Passageway was based on the localtunnel project. It installs an agent on your local machine which forwards requests to a specific port to Runscope, and Runscope then creates a public URL. You can use Passageway to show off code running on your local machine, but you can also use it for debugging webhooks and testing API’s used in a mobile application (by pointing it at the public Runscope URL). Scott says he sees this as being useful in a continuous integration environment, and John says that a current customer is already doing this.
      • (27:33) Jon asks about the installation via pip, and John explains how pip relates to other package managers. They plan to provider other installers, and later the agent will do more than just Passageway – right now it also supports automatically creating Runscope urls for requests.
      • (29:27) Jon says that Passageway is the first place on the site where he sees something about paid accounts and asks John how they’re going to get rich. John says there are three reasons (access to passageway, team sharing and volume) to upgrade from a free account to a starter or team account. Jon asks about the naming of the starter account, and John says that naming and pricing are really hard. Scott offers some advice on enterprise friendly pricing.
  • Starting a business
    • (32:47) Jon asks about the experience of moving from being a developer to founding a company. John says he’s started several small companies, and writing software has always been a way to solve problems for businesses. He tells his recent job history at Twilio and IFFT and how he and his co-founder Frank got really fed up with the lack of good API developer tools and how they got started, funded, and launched. Getting funded was both a finish line and a starting line.
    • (41:33) Scott and Jon talk about positive response they saw to the GlueCon launch: John spent the majority of the time describing the problem, then unveiled the solution. Scott compares John to Steve Jobs.
  • What’s next
    • (43:05) Jon asks what’s next. John says they’re first focusing on dev-time troubleshooting. Next they’ll be focused on production use, especially high volume use cases. Long term they’re thinking about mitigating problems – handling or proactively monitoring for problems.
  • Python
    • (45:14) Jon asks about John’s experiences building Runscope in Python and how he compares it to .NET. John says he’s really come around to significant whitespace and standard
    • (46:59) Scott asks if John’s noticed that there are fewer ways to solve a problem, as opposed to C# or JavaScript. John says that’s true for the most part. He comments on how he likes the small libraries and ecosystem.
  • Runscope vs. other network tools like Fiddler and Wireshark
    • (49:19) Scott asks why you’d use Runscope rather than use things like Fiddler, Wireshark, etc. John explains proxies and applications modify the way the application works and doesn’t work well on servers – it’s cloud-native. It’s also social – sharing is built in. Thirdly, it’s not a desktop application.
    • (52:30) John says he’d like to write a Fiddler plugin to make the two work well together. Scott says that there’s one advantage to desktop applications – it can interact directly with the network stack. John agrees that developers need tools that work at all layers of the stack. Scott recounts a harrowing tale in which Fiddler had to be installed on a server for an application to work.
    • (55:20) Jon says he was wondering about integrating with Glimpse but that would require an API – does Runscope have an API? John says one’s on the way soon.
  • Lightning Round inspired by John’s Traffic and Weather podcast (with Steve Marx)
    • (57:00) Jon says he’s really been enjoying the Traffic and Weather podcast, and the John and Steve have convinced him that API’s really can be interesting.
    • (57:50) JSON API – what is it, and is it good?
    • (59:34) What are webhooks, and why have you been talking about them?
    • (1:01:52) Should we stop writing REST SDK clients?
    • (1:04:29) Where is API security going? Is it OAuth 2 from here on out?
    • (1:05:21) Eric Williams (@motowilliams) asks "Ping Pong or Foosball? #gooooooaaaaaallll"
    • (1:06:17) Where are you speaking next (answer: API Days and API World, both in San Francisco)
    • (1:07:32) Do you support the HTTP 418 teapot response?

Show Links:

CategoriesUncategorized