Fork me on GitHub

Project Notes

Request Bin

Using request bin services to inspect HTTP events - Runscope self-hosted and newer Pipedream services with workflows aka programmable bins.

Notes

I was a long-time user of the old Runscope requestb.in service for capturing real payloads from live services. It was a shame when they had to shutter the public service due to abuse, but the silver lining was how they open-sourced a version of requestbin that we could run for ourselves.

Runscope have since focused on their core API monitoring service.

As I was updating my notes on running a request bin, I stumbled upon a new(?) player in town - Pipedream. As far as I can tell, they only have the free offering for now, but are planning toadd paid tiers in future.

I took pipedream for a test drive and was really impressed - in addition to being slickly integrated, the workflow features make it the IFTTT of request bining.

Self-hosting requestbin

See the requestbin repo for instructions. It is trivial to deploy a personal instance to heroku:

$ git clone git://github.com/Runscope/requestbin.git
$ cd requestbin
$ heroku create
$ heroku addons:add heroku-redis
$ heroku config:set REALM=prod
$ git push heroku master

The application runs with the classic Runscope interface…

self_hosted_requestbin

Using Pipedream

Pipedream run two services:

  • requestbin.com offers traditional request bins; the original service from Pipedream launched Dec 2018. It will apparently continue as a stand-alone service.
  • pipedream.com which has all the new goodness - including private bins, logging and workflows. Publically launched in Oct 2019.

Simple Request Bins

The requestbin.com domain offers the choice of public or private request bins, or workflows..

requestbin

Choosing a public request bin behaves very much like good old requestb.in, but with a snazzier UI:

public_bin

Workflows - Programmable Bins

The funs starts when you choose a worflow, or go direct to pipedream.com:

pipedream

A workflow basically means that instead of just logging the incoming payload, it is possible to configure/script a series of steps that can, for example:

  • inspect and log details of the request
  • transform or process the request
  • log data for later analysis or use
  • trigger external services
  • send notifications e.g. via email, SMS
  • trigger a “smart reply”

A good first step is to explore featured workflows and play with them, with occassional reference to the docs of course.

Workflow Example

I copied some ideas from featured workflows and put together a neat little service that doesn’t even need an incoming trigger request.

The “Mail me new items from the LEAP feed” is:

All pretty cool for something that started life as an web request monitor!

The workflow editor is pretty slick, and I believe powered by the Monaco editor.

Here’s my workflow in the editor (anyone can copy the workflow and make their own changes):

leap_wf

It generates a simple text mail that is delivered through pipedream’s servers FOC!

leap_wf_mail

Credits and References

About LCK#120 toolsapi
Project Source on GitHub Return to the Project Catalog

This page is a web-friendly rendering of my project notes shared in the LittleCodingKata GitHub repository.

LittleCodingKata is my collection of programming exercises, research and code toys broadly spanning things that relate to programming and software development (languages, frameworks and tools).

These range from the trivial to the complex and serious. Many are inspired by existing work and I'll note credits and references where applicable. The focus is quite scattered, as I variously work on things new and important in the moment, or go back to revisit things from the past.

This is primarily a personal collection for my own edification and learning, but anyone who stumbles by is welcome to borrow, steal or reference the work here. And if you spot errors or issues I'd really appreciate some feedback - create an issue, send me an email or even send a pull-request.