Blog

<p>Bipio lets you create cheap dynamic endpoints quickly and have them perform some complex task, so when our LaunchRock page failed after a recent account migration (they were super helpful in debugging, no love lost) it seemed like a perfect opportunity to build a similar email capture widget using the toolset already baked into <a href="https://bip.io/docs" target="_blank">our API</a>. Time to <a href="http://en.wikipedia.org/wiki/Eating_your_own_dog_food" target="_blank"> Eat Our Own Dogfood</a>, as it were, as a simple exercise I could fit into a saturday morning between breakfast coffee and brunch coffee. Great!<br /><br /><br /> The requirements for the widget were, at their core, very simple - for every user that arrived at the home page, I wanted to create a temporary, single use endpoint which took an email address, passed it to a data store and sent a thankyou message. Maybe later I can <a href="https://bip.io/docs#pod_syndication" target="_blank">render this syndication</a> into excel files containing batches of 100 leads for onboarding (because we can), but for now, just keep it simple. Don&rsquo;t want to be late for brunch. Enter the Candy Strip. It&rsquo;s a little dynamic call to action widget that you can find on <a href="https://bip.io" target="_blank">our home page</a>, and it took all of 30 minutes to set up. Fun Fact&nbsp;: Although the website itself is a blocking architecture PHP/Zend stack, creating these endpoints takes ~10ms across our DMZ to the API, a barely noticeable hit to application performance and we get a bunch of functionality that can be easily extended at no cost to application complexity. <br /><br /><br /><br /> So, we can create these endpoints right out of the box with HTTP Bips, with all the normal characteristics of a Bip including temporary lifespan, authentication scheme, dynamic naming and a predictable data export. To have that bip send an email and store some data, I just need to create a simple Hub (graph) with two channels (vertices) which are to send a transactional Email (email.<em>transaction), and list email addresses to a List Syndication (syndication.list). <br /><br /><br /><br /> To create the syndication, just POST /rest/channel a little packet pointing at the Syndication Pods &lsquo;list&rsquo; action. The list action is perfect because it gives me the option to render everything we&rsquo;ve received to a CSV, TSV or Excel file down the track. Channels are re-usable across Hubs, so this Channel could now act as a datasource for a different hub sitting outside this email capture workflow if I don&rsquo;t want to add more actions to the pipeline. <br /><br /><br /></em></p>
<pre class="prettyprint"><code> <br />
{
"config": {
"write</code></pre>
<p>mode": "append" }, "action": "syndication.list", "name": "Signup Reservation List" } <br /> Done! The data store gets created, and every line item we get in this list is appended to the store<br /><br /><br /> Just black holing content into a syndication isn&rsquo;t very useful, so I wanted to send an email to the early adopter thanking them for their interest. I used the email template we already had for LaunchRock so didn&rsquo;t have to don my Marketing Hat before lunchtime. Bonus, only 10 minutes in so far! <br /><br /><br /></p>
<pre class="prettyprint"><code> <br />
{
"action": "email.<em>transaction",
"config": {
"template": "beta</em>registered",
"from": "Bipio Signups ",
"subject": "A quick update about your beta invite"
}
"name": "Email Capture Receipt"
}
</code></pre>
<p><br /> email.<em>transaction is a special Email Pod action we have for sending pre-baked transactional messages, you won&rsquo;t find them in the API just yet, sorry! <br /><br /><br /><br /> We now have two Channels for processing the capture, so in the website controller code, I&rsquo;ll just make a call out to the API when the page renders and assemble these Channels onto a Hub with a <em>POST /rest/bip</em>. The name of the bip matches the session id in our application, they&rsquo;re single use or naturally expire after a day. Together between the size of our capture syndication, and the number of created http bips, I can also figure out a rough conversion rate. The &lsquo;</em>repr&rsquo; attribute in the <em>POST /rest/bip</em> response payload tells the widget which endpoint URI to send the email address to in our eventual AJAX request. _repr means the string representation of the object, all REST resources in Bipio have this decorator, harking back to the systems <a href="http://www.tornadoweb.org/en/branch2.4/" target="_blank">Tornado</a> roots. <br /><br /><br /></p>
<script src="https://gist.github.com/cloudspark/5126087.js" type="text/javascript"></script>
<p><br /><br /><br /> If I hit the website, I see a new HTTP bip in the &lsquo;beta.bip.io&rsquo; account dashboard whose name matches my session id, so its working. The graph for my temporary bip renders like so&nbsp;: <br /><br /><br /><br /><img src="http://media.tumblr.com/6e271724c0b4b5a7ae150b937894d12c/tumblr_inline_mjip1fjGMm1qz4rgp.png" alt="image" /><br /><br /><br /><br /> Now to expose the widget in the view and slap it some lipstick courtesy of <a href="http://www.colourlovers.com/pattern/925809/little_rainbows" target="_blank">cameo &amp; ycc2106 @ colourlovers</a>&nbsp;: <br /><br /><br /></p>
<script src="https://gist.github.com/cloudspark/5126126.js" type="text/javascript"></script>
<p><br /><br /><br /><img src="http://media.tumblr.com/7dc471a84933b53ce39b792caec5ff08/tumblr_inline_mjintnGKTM1qz4rgp.png" alt="image" /><br /><br /><br /><br /><img src="http://media.tumblr.com/4d97b325db38ffc1146a05ea21710f83/tumblr_inline_mjipr8uJ6Y1qz4rgp.png" alt="image" /><br /><br /><br /></p>
<p>And we&rsquo;re done :)</p>