Author Archive

The Edge is Nothing Without the Fog

Edge computing is hot right now. The growing maturity of IoT networks ranging from industrial to VR applications means that there’s an enormous amount of discussion around moving from the cloud to the edge (from us as well). But edge computing is only the first step.

We first want to makes sure we define the terms we’ll use.

  • The edge refers to the devices, sensors, or other sources of data at the edge of the network.
  • The cloud is the datacenter at the “center” of the network.
  • The fog is a management layer in-between the two (we know this is vague, read on)

More data, more problems

As more and more devices become connected to networks, we’re going to see an enormous uptick in the amount of data generated. Andy Daecher and Robert Schmid of Deloitte believe that “globally, the data created by IoT devices in 2019 will be 269 times greater than the data being transmitted to data centers from end-user devices and 49 times higher than total data center traffic.” Calling this big data is an understatement.

These volumes of data mean big problems:

  1. Moving this amount of data means latency issues for networks
  2. Privacy and security concerns increase as more data is moved
  3. Devices sending more data require more hardware and power to run

Prioritization is the answer, but it’s not solved at the edge

The answer to increasing data volume is the fog: the prioritization and management layer on the continuum between the edge and the cloud. The fog needs to answer the crucial decision: what to analyze at the end, and what to push back to the cloud?

It’s unreasonable to expect an IoT sensor at the edge (like a drone, that requires sub-millisecond reaction times), to process all the data it collects in realtime or push that data all the way to the cloud for processing. The fog reduces latency and takes the processing load off the drone, acting as a management layer and allowing for efficient distribution of resources across the network.

So, what does architecture incorporating the cloud, the edge, and the fog look like?

Justin Baker of RealtimeAPIHub has an excellent guide, including this graphic from Ergomonitor:


Intelligently separating data analysis tasks across the network continuum will be crucial as we move forward into the next era of IoT.

Examining Mature APIs (Slack, Stripe, Box)

In our previous blog post, we discussed the disconnect between API pricing plans where you pay monthly for a set number of calls and regular developer use cases. We think competition will drive new pricing models that are more developer friendly – and a potential approach could be charging for calls based on their business value. Examining webhook events available via API from Stripe, Slack, and Box gives us a forward look into how this could work.

What’s a mature API?

Forbes nicely summarizes where they see API development going in this graphic (ignore the “customer-driven platform revolution”) portion:


They make a valid point that APIs become more valuable as the data that flows from them becomes bi-directional – APIs are not only returning data based on calls, but actively pushing out data based on API activity.

This data push generally starts around activity with high business value – so we’re going to examine APIs from Stripe, Slack, and Box to get an idea of what events they make available.

Slack has a separate “Events API”

Slack has chosen to implement a separate Events API for developers who want to build apps that respond to events within Slack. Here’s the full list of event types that they can push in realtime as they happen.

Looking at this list in more detail, it’s focused around key messaging and collaboration activities:

  • Creating and updating channels
  • Uploading, sharing, and commenting on files
  • Messages being posted to various channels

Box uses event triggers

Box uses webhooks with event triggers attached to Box files and folders to monitor events attached to files and folders and notify you when they occur. Here’s their full list of events for files and folders.

As expected for Box, events are focused around file management and collaboration:

  • Uploading, previewing, and downloading files
  • Comment and task assignment creation and updating

Stripe sends a variety of events

Stripe sends a wide variety of events around payments, both keyed to internal and external usage:

  • Account creation and updating
  • Product or plan creation
  • Card charges and updates

What does it mean?

The events that these mature APIs have chosen to make available for realtime push have substantial business value for developers building apps using their functionality. As more APIs begin to offer push of data, they may move to a blended pricing model that charges more for these high-value events. We’re interested to see what happens!

Realtime data for smart notifications

From the Fanout Blog

It’s becoming the new normal that messaging and collaboration apps and platforms are available across multiple devices.

Business tools like Slack and JIRA offer feature-rich mobile apps, and users increasingly consume content from social networks like Facebook on their mobile devices instead of a desktop or laptop.

This isn’t a surprise – and we’re here to share our perspective on how developers can use realtime data to provide cross-platform users with the best notification experience.

Mary Meeker’s 2017 Internet Trends Report tracks the trend towards increasing mobile adoption:


What’s not stated explicitly in this slide is that that much of this engagement occurs simultaneously – it’s not uncommon for users to have an app open on their desktop and phone at the same time.

‘Dumb’ notifications produce a poor user experience

Simultaneous use of cross-platform apps has created a user experience issue that many of us are familiar with. When a new Trello card is assigned to me, I get a push notification on my phone, a ping in the Trello interface, and an email in my inbox. Due to my Trello integration with Slack, things quickly get worse – I get a notification on Slack on each of my devices. I can get up to 6 notifications tied to a single event.

This isn’t ideal – and as more devices become connected, the problem will only be compounded. Imagine a future where your phone, smartwatch, smart TV, and smart thermostat are all buzzing simultaneously. It doesn’t need to be this way.

Collaboration and messaging app developers can get smart

We didn’t come up with the idea of ‘smart’ notifications (entire companies like Intercom and OpenBackare built to enable them) – but we do have a perspective on how app developers can use realtime data to enable them.

Realtime data is already present in many chat or collaboration apps – typing indicators, read receipts, and live editing are all features that we take for granted. The next step for developers is taking a wider variety of realtime data into account when building notifications into their user experiences.

Luckily, mobile devices offer a wealth of realtime data to developers who want to do this:

Presence and attention-awareness (knowing which device a user is active on) allows a single ping to that device, instead of a ping to all devices. Results-driven logic can drive a secondary notification to another device or channel in the instance the first notification is not responded to. This can lead to some pretty complex logic, as in the case of Slack’s notification tree below:


Slack’s blog post on how they built a lightweight desktop client to handle the complex interactions between team, channel, and user preferences and states when sending notifications is worth reading.

Time and location data is crucial – work notifications don’t need to be sent on the weekend, and pop-up notifications for events or sales are only relevant in bounded areas. Slack enables manual setting of ‘Do Not Disturb’ hours in order to keep notifications from taking over user’s lives. Context can be user-generated (like in the Slack example) or learned based on prior interactions with notifications.

Device and connection state information is underutilized. Know a user has low battery life? Maybe the notification to download the latest game update can wait. Users on Wifi are more likely to interact with rich notifications than those on cellular connections. If a user loses connectivity and many notifications are queued, they may no longer all be relevant when the user is back in range.

Realtime is a crucial component for smart notifications

As users constantly switch devices and platforms, realtime knowledge of their status is key to providing intelligent notifications. Developers who do this well will continue to retain user interest, and those who don’t will have a hard time keeping their attention.

What is a realtime API?

Many software developers are familiar with realtime, but we believe that realtime concepts and user experiences are becoming increasingly important for less technical individuals to understand.

At Fanout, we power realtime APIs to instantly push data to endpoints – which can range from the actual endpoints of an API (the technical term) to external businesses or end users. We use the word in this post loosely to refer to any destination for data.

We’re here to share our experience with realtime: we’ll provide a definition and current examples, peer into the future of realtime, and try and shed some light on the eternal realtime vs. real-time vs. real time semantic debate.

The simple definition

Realtime refers to a synchronous, bi-directional communication channel between endpoints at a speed of less than 100ms.

We’ll break that down in plain[er] english:

  • Synchronous means that both endpoints have access to data at the same time (not to be confused with sync/async programming).
  • Bi-directional means that endpoints can send data in either direction.
  • Endpoints are senders or receivers of data: they could be anything from an API endpoint that makes data available to a user chatting on their phone.
  • 100ms is somewhat arbitrary: data cannot be delivered instantly – but under 100ms is pretty close, especially with respect to human perception. Robert Miller proved this in 1986.

An example of a realtime user experience

A simple example of a realtime user experience is that of a chat app. In a chat app, you ‘immediately’ (sub 100ms) see messages from the person (endpoint) you’re chatting with, and can receive information about when they read your messages (synchronous, bi-directional).

Realtime vs. request-response

Web experiences are beginning to move from request-response experiences to live, realtime ones. Social feeds don’t require a refresh (a request) to update, and you don’t need to email documents as attachments that need to be downloaded (request) and sent back with edits (response) – you just use collaboration software that works in realtime.

More realtime experiences

Realtime user experiences are everywhere you look – especially where near-instant access to information is valuable. You’ll find realtime in:

  • Collaboration: realtime access to internal and external information from your team is becoming the norm. It’s accepted that a sales inquiry (data) can be instantaneously relayed from live chat on your website, into your customer service portal and then into Slack.
  • Finance: stock tracking and bitcoin wallets require immediate access to information. Applications like high-frequency trading exist specifically because of the ability of certain parties to access and act on data faster than others.
  • Events: second-screen experiences for sports, including live betting with realtime odds updates, are becoming increasingly common.
  • Crowdsourcing: distributed collection, analysis, and dissemination of data from distributed endpoints (think reports from WeatherUnderground stations or from the traffic app Waze) is only valuable when it occurs in realtime.

Realtime in the future

As we see it (and admittedly, we are a little biased), realtime is quickly becoming the new normal. Up-to-date information is expected by businesses and end users. Realtime is the natural complement to trends like:

Big Data: as the number of digitally connected businesses, experiences, and devices rises, so does the amount of data generated. Data becomes more valuable as the three V’s of a dataset (velocity, volume, variety) increase – and realtime transmission is central to the velocity component.

In the past, companies benefitted from hoarding data, but increasingly data is becoming most valuable when shared (and monetized). The companies that can aggregate and share the most data, as quickly as possible, will be successful.

Proliferation of APIs: businesses sharing data are increasingly going to do so through APIs. Entire businesses are being built on APIs by platform providers like Twillio (they only have an API) or they are coming to comprise substantial portions of existing businesses (like Salesforce’s API).

An elegant end-user experience is increasingly the product of data that’s being moved through multiple APIs – and the number of APIs is only going to increase as they trend towards becoming less technical and more accessible and interoperable. The APIs that provide access to data or move it through their system as quickly as possible will rise over those that cannot.

Realtime vs. real-time vs. real time

The endless debate – what’s the correct way to write what we’ve been discussing? We use realtime, because we believe that “real time” refers to something experienced at normal speed and not condensed or sped up. For example, watching grass grow in ‘real time’ is not very exciting – but a time lapse is.

We also don’t like hyphenating – so we went with realtime instead of real-time (and it looks like most of the industry agrees with us).