Author Archive

Spotlight Article: 2017 Is Quickly Becoming The Year Of The API Economy by Louis Columbus

In his article, Louis Columbus discusses how the urgency to create new business models has catalyzed the proliferation of public facing / monetizable APIs.

This year more CIOs will have their bonuses tied to how many new business models they help create with existing and planned IT platforms than ever before. This trend will accelerate over the next three years. CIOs and IT staffs need to start thinking about how they can become business strategists first, technicians and enablers of IT second. CIOs must create and launch new business models faster to keep their companies competitive. APIs are the fuel helping to make this happen.

Full Article

Ruby/Rails Realtime Resources

This section highlights the realtime resources available for Ruby / Rails developers.


Realtime Ruby/Rails Libraries

Actioncable: Integrated WebSockets for Rails – Action Cable seamlessly integrates WebSockets with the rest of your Rails application. It allows for real-time features to be written in Ruby in the same style and form as the rest of your Rails application, while still being performant and scalable. It’s a full-stack offering that provides both a client-side JavaScript framework and a server-side Ruby framework. You have access to your full domain model written with Active Record or your ORM of choice.

Plezi: A Ruby framework for realtime web applications – Plezi is a Ruby framework for realtime web applications. It’s name comes from the word “pleasure”, since Plezi is a pleasure to work with. With Plezi, you can easily: Create a Ruby web application, taking full advantage of RESTful routing and scalable Websocket features; Add Websocket services your existing Web-App, (Rails/Sinatra or any other Rack based Ruby app); Create an easily scalable backend for your SPA.

Pakyow: A realtime Ruby web framework – Pakyow is a Ruby web framework that lets you create fantastic experiences for your users without writing any client-side code. Build modern server-driven applications that don’t compromise on speed or usability. Pakyow automatically keeps your presentation layer in sync with state of the server. It works out of the box with no additional code.  Create a working prototype of your project with plain HTML. Later, build right on top of the prototype without throwing it out. We think that a democratic web presupposes a simpler web. Pakyow optimizes for simplicity, which makes it easier to start and leads to long-term productivity.

Firehose: Build realtime Ruby web applications. Created by Poll Everywhere – Firehose is both a Rack application and JavaScript library that makes building real-time web applications possible.

Slack Ruby Client: A Ruby and command-line client for the Slack Web and Real Time Messaging APIs. –  A Ruby client for the Slack Web and RealTime Messaging APIs. Comes with a handy command-line client, too. If you are not familiar with these concepts, you might want to watch this video.

Realtime Rails: Realtime rails support – As of mid-2015, support for performant, native and scalable websockets are available in Rails. See ActionCable, which landed in Rails 5 and will probably be officially released early/mid 2016.  As such, with ActionCable‘s design, you don’t even need a separate pub/sub server (redis) and Node.js running anymore to achieve similar lightweight realtime bi-directional communication with a large number of connected clients to your Rails application.

Awesome Ruby:  A collection of awesome Ruby libraries, tools, frameworks and software – A categorized community-driven collection of awesome Ruby libraries, tools, frameworks and software. The essential Ruby to build modern Apps and Web Apps.

Unimidi: MIDI IO for Ruby – A platform independent realtime MIDI input and output for Ruby. Also see MicroMIDI which builds a full MIDI messaging DSL on top of this library.

Cramp: Real-time web application framework in Ruby – Cramp is a fully asynchronous realtime web application framework in Ruby. It is built on top of EventMachine and primarily designed for working with larger number of open connections and providing full-duplex bi-directional communication.

Render_Sync: Realtime rails partials – Real-time partials with Rails. Sync lets you render partials for models that, with minimal code, update in realtime in the browser when changes occur on the server.


Realtime Web Applications with Ruby on Rails

Specs

  • Author: Codescrum
  • August 2016

Resources

Synopsis

Ruby on Rails can be used now to build real-time web applications out of the box! From version 5, the Rails framework incorporates ActionCable, an integrated websocket implementation. ActionCable is a full-stack offering that provides both a client-side JavaScript framework and a server-side Ruby framework.

 


Realtime Web Apps with Volt in Ruby

Specs

  • Author: Dhaivat Pandya
  • February 2015

Resources

Synopsis

Volt is a slick, new Ruby web framework that aims to blur the line between client and server code. The basic idea behind the framework is that you can write your client-side code (which is usually Javascript) in Ruby using Opal, a Ruby runtime within Javascript. In addition, Volt provides some nice ways to relay data between the client-side and the server-side. If you’ve used Meteor before, Volt is a very similar idea, but there are many portions of Meteor which Volt doesn’t have. I think Volt has some real potential. As web apps become more and more client-side heavy, it is a pain to have to switch mental context between Javascript and Ruby. It’s even more of a pain to figure out how to flow simple pieces of data between the client and server. Volt can help you get there quickly.

In this article, I’ll go through how to build an incredibly simple bookmark “app” with Volt. The point of this article is to get you up to speed with some of the very basics and to get you a feel for how the client/server divide works in Volt. Let’s get to it.


Real-Time Rails: Implementing WebSockets in Rails 5 with Action Cable

Specs

  • Author: Sophie Debenedetto
  • May 2016

Resources

Synopsis

Recent years have seen the rise of “the real-time web.” Web apps we use every day rely on real-time features—the sort of features that let you see new posts magically appearing at the top of your feeds without having to lift a finger.

While we may take those features for granted, they represent a significant departure from the HTTP protocol’s strict request-response pattern. Real-time web, by contrast, loosely describes a system in which users receive new information from the server as soon as it is available—no request required.

There are a number of strategies and technologies for implementing such real-time functionality, but the WebSocket protocol has been rising to prominence since its development in 2009. However, up until very recently, implementing the WebSocket protocol in Rails was difficult. There was no native support, and any real-time feature required integrating third party libraries and strategies like Faye or JavaScript polling. So let’s take a closer look at WebSockets and how Rails 5 has evolved to support real-time apps with Action Cable.


Realtime Infrastructure Services

  • Realtime API Infrastructure – Realtime API infrastructure specifically allows developers to build realtime data push into their existing APIs.  Typically, you would not need to modify your existing API contracts, as the streaming server would serve as a proxy. The proxy design allows these services to fit nicely within an API stack. This means it can inherit other facilities from your REST API, such as authentication, logging, throttling, etc. It can be combined with an API management system.  In the case of WebSocket messages being proxied out as HTTP requests, the messages may be handled statelessly by the backend. Messages from a single connection can even be load balanced across a set of backend instances.
    • Fanout/Pushpin – Fanout is a real-time API development kit that helps you push data to connected devices easily. Fanout is a cross between a reverse proxy and a message broker. Pushpin is the open source version.
    • Streamdata.io – Streamdata.io a SaaS API proxy tool that converts standard API requests into a streaming API. In other words, it provides a proxy as a service for any HTTP API by polling and acting as a streaming API.
    • LiveResource – LiveResource is a protocol specification and JavaScript reference library for receiving live updates of web resources. It has the following principles:
  • Realtime Application Infrastructure – Realtime app infrastructure sends data to browsers and clients. It typically uses pub/sub messaging, webhooks, and/or websockets — and is separate from an application or service’s main API.
    • Firebase – Firebase is a BaaS (Backend-as-a-Service) that allows developers to create web applications with no server-side programming required.
    • Pubnub – PubNub is a programmable Data Stream Network (DSN) and realtime infrastructure-as-a-service (IaaS) company. Primarily, they are a messaging solution hosted on a cloud service that allows developers to publish data instantly to one or multiple devices.
    • Pusher – Pusher is a hosted service that allows developers to add realtime bi-directional functionality via WebSockets (with HTTP-based fallbacks) to the web and mobile apps.
    • Ably – Ably is a realtime data delivery platform that provides creators the tools to create, deliver, and manage projects. Their main realtime functionality consists of pub/sub, presence, authentication, encryption, and connection state recovery.

Go Realtime Resources

This section highlights the realtime resources available for Go developers.  Go is a programming language that is particularly well suited for high-performance, realtime web applications.


Realtime Go Libraries

uilive: a go library for updating terminal output in realtime –uilive is a go library for updating terminal output in realtime. It provides a buffered io.Writer that is flushed at a timed interval. uilive powers uiprogress.

rtsupportserver: Go Server for Realtime Web App Course – This repo contains the source for the Golang server build for the following course on Building Realtime Web Apps with Reactjs, Golang & RethinkDB http://courses.knowthen.com/courses/learn-how-to-develop-realtime-web-apps.  This Course Teaches you everything you need to know to build Realtime Web Apps using React, Golang & RethinkDB.

Go Chat: A simple realtime chat application written in Go – This is a simple chat web app written in Go

NSQ: A realtime distributed messaging platform – NSQ is a realtime distributed messaging platform designed to operate at scale, handling billions of messages per day. It promotes distributed and decentralized topologies without single points of failure, enabling fault tolerance and high availability coupled with a reliable message delivery guarantee.

Centrifugo: Language-agnostic real-time messaging (Websocket or SockJS) server in Go – Centrifugo is a real-time messaging server. It’s language-agnostic and can be used in conjunction with application backend written in any language – Python, Ruby, Perl, PHP, Javascript, Java, Objective-C etc.  Centrifugo runs as separate service and keeps persistent Websocket or SockJS connections from your application clients (from web browsers or other environments like iOS or Android apps). When some event happens you can broadcast it to all interested clients using Centrifugo API.

godnsbl: Go library for RBL (Real-time Blackhole List) lookups – Package godnsbl lets you perform RBL (Real-time Blackhole List – https://en.wikipedia.org/wiki/DNSBL) lookups using Golang

GoRealtimeWeb: Examples how to write realtime web applications in Golang – Examples how to write realtime web applications in Golang. This repository contains examples for the following real-time implementations: Server-sent events, Long Polling, Websocket Most of the long polling systems close the connection after each transmission from the server, with the help of oboe.js this example can handle multiple messages from the server in realtime without closing/reconnecting.

Gor: HTTP traffic replay in real-time. Replay traffic from production to staging and dev environments. – Gor is a simple http traffic replication tool written in Go. Its main goal is to replay traffic from production servers to staging and dev environments. Now you can test your code on real user sessions in an automated and repeatable fashion.  Gor consists of 2 parts: listener and replay servers. The listener server catches http traffic from a given port in real-time and sends it to the replay server. The replay server forwards traffic to a given address.

Awesome-Go: A curated list of awesome Go frameworks, libraries and software – A curated list of awesome Go frameworks, libraries and software. Inspired by awesome-python.


GoLang in Realtime

Specs

  • Golang’s Real-time GC in Theory and Practice
  • Author: Pusher, Will Sewell
  • December 2016

Resources

Synopsis

Garbage collectors are a bane of real-time systems because they pause the program. So when designing our new message bus, we chose the language carefully. Go emphasizes low latency, but we were wary: does Go really achieve this? If so, how?

In this blog post, we’ll look at Go’s garbage collector. We’ll see how it works (the tricolor algorithm), why it works (achieving such short GC pauses), and most importantly, whether it works (benchmarking these GC pauses, and comparing them with other languages).


A Real Time Chat App With Golang, Angular 2, And Websockets

Specs

  • Create A Real Time Chat App With Golang, Angular 2, And Websockets
  • Author: The Polyglot Developer, Nic Raboy
  • December 2016

Resources

Synopsis

I’ve been hearing a lot about websockets lately and how they can accomplish real time communication between applications and servers. They act as a compliment and possible alternative to RESTful APIs that have been around for significantly longer. With websockets you can do real time messaging for things like chat, communication with IoT, gaming, and a whole lot of other things that need instant communication between clients and the server.

A while back I had played around with websockets and Node.js using a library called Socket.io, but since I’ve been really getting into Golang I wanted to explore websockets using the Go programming language.

We’re going to check out how to create a chat application where the client is an Angular 2 application and the server is a Golang application.


Real-Time Web Apps in Go: Chat

Specs

  • Writing Real-Time Web Apps in Go: Chat
  • Author: Ola Holmström
  • September 2015

Resources

Synopsis

Go is a programming language that is particularly well suited for high-performance real-time web applications. Go is both faster and more memory efficient than most other popular alternatives, you’d think this would come at a cost of expressiveness but writing a meaningful real-time web app can be done in only a few lines.


Realtime Infrastructure Services

  • Realtime API Infrastructure – Realtime API infrastructure specifically allows developers to build realtime data push into their existing APIs.  Typically, you would not need to modify your existing API contracts, as the streaming server would serve as a proxy. The proxy design allows these services to fit nicely within an API stack. This means it can inherit other facilities from your REST API, such as authentication, logging, throttling, etc. It can be combined with an API management system.  In the case of WebSocket messages being proxied out as HTTP requests, the messages may be handled statelessly by the backend. Messages from a single connection can even be load balanced across a set of backend instances.
    • Fanout/Pushpin – Fanout is a real-time API development kit that helps you push data to connected devices easily. Fanout is a cross between a reverse proxy and a message broker. Pushpin is the open source version.
    • Streamdata.io – Streamdata.io a SaaS API proxy tool that converts standard API requests into a streaming API. In other words, it provides a proxy as a service for any HTTP API by polling and acting as a streaming API.
    • LiveResource – LiveResource is a protocol specification and JavaScript reference library for receiving live updates of web resources. It has the following principles:
  • Realtime Application Infrastructure – Realtime app infrastructure sends data to browsers and clients. It typically uses pub/sub messaging, webhooks, and/or websockets — and is separate from an application or service’s main API.
    • Firebase – Firebase is a BaaS (Backend-as-a-Service) that allows developers to create web applications with no server-side programming required.
    • Pubnub – PubNub is a programmable Data Stream Network (DSN) and realtime infrastructure-as-a-service (IaaS) company. Primarily, they are a messaging solution hosted on a cloud service that allows developers to publish data instantly to one or multiple devices.
    • Pusher – Pusher is a hosted service that allows developers to add realtime bi-directional functionality via WebSockets (with HTTP-based fallbacks) to the web and mobile apps.
    • Ably – Ably is a realtime data delivery platform that provides creators the tools to create, deliver, and manage projects. Their main realtime functionality consists of pub/sub, presence, authentication, encryption, and connection state recovery.

Java Realtime Resources

This section highlights the realtime resources available for Java developers.


Realtime Java Libraries

Realtime Cloud Messaging Java SDK – Part of the The Realtime® Framework, Realtime Cloud Messaging (aka ORTC) is a secure, fast and highly scalable cloud-hosted Pub/Sub real-time message broker for web and mobile apps. If your application has data that needs to be updated in the user’s interface as it changes (e.g. real-time stock quotes or ever changing social news feed) Realtime Cloud Messaging is the reliable, easy, unbelievably fast, “works everywhere” solution.

Atmosphere: The Asynchronous WebSocket/Comet Framework – The Atmosphere Framework contains client and server side components for building Asynchronous Web Applications. The majority of popular frameworks are either supporting Atmosphere or supported natively by the framework. The Atmosphere Framework supports all major Browsers and Servers.

OneBusAway: Java classes generated for GTFS-realtime extensions – This project contains Java libraries generated from the OneBusAway-specific and NYCT-specific GTFS-realtime protocol buffer extensions.

Intrinio: Java SDK for Real-Time Stock Prices – Intrinio provides real-time stock prices via a two-way WebSocket connection.

Firebase: Java Realtime Database Quickstart – The Java Firebase Database quickstart demonstrates how to connect to and use the Firebase Realtime Database using Java through a simple social blogging app. It will interoperate with the Web, iOS and Android database quickstarts.

jInstagram: A Java library for the Instagram API – An unofficial Java library for the Instagram API. Note : jInstagram uses code from the scribe-java library developed by Pablo Fernandez.

Symphony Java Client – The Symphony java client provides a real-time wrapper around the Symphony REST API’s to simplify the creation of chat sessions, room access, presence, messaging and more… The client provides a set of logical services representing supported features of the Symphony platform. Services support real-time events through feature based listeners and communication objects. Access is not limited to the services as all underlying Symphony client implementations are exposed for advanced use or creation of your own service.


Java SE APIs

Specs

  • Developing Realtime Software with Java SE APIs.
  • Author: Oracle, Kelvin Nilsen
  • August 2014

Resources

Synopsis

The use of Java SE APIs in the implementation of real-time systems is most appropriate for soft real-time development. Using Java SE for hard real-time development is also possible, but generally requires the use of more specialized techniques such as the use of NoHeapRealtimeThread abstractions, as described in the Real-Time Specification for Java (JSR 1), or the use of the somewhat simpler ManagedSchedulable abstractions of the Safety Critical Java Technology specification (JSR 302).

It is also important to distinguish real-time engineering, as it is described in this series, from performance engineering. An e-commerce web server, for example, might have been carefully engineered to support an average of 1,000 transactions per second. That is different from saying that every transaction must be completed in 1 ms. It could be that some transactions require hundreds of ms and others are completed in less than 1 ms, as long as the average of all transactions is 1 ms. It could also mean that each transaction requires an average of 4 ms from start to end, but the system has the ability to concurrently execute four transactions at a time.

The benefits of the Java language are especially valuable in real-time applications that are large, complex, and dynamic. Software engineers are motivated to select Java SE when their projects require dynamic code updates, coordination between multiple teams of developers, integration of independently developed software components, support for multiple hardware or operating system platforms, or support for multiple software configurations as product requirements evolve over multiple years or even decades.


Intro to Realtime Java

Specs

  • Real-Time Java: An Introduction
  • Author: O’Reilly, Peter Mikhalenko
  • May 2006

Resources

Synopsis

Real-time application development requires an API set and semantics that allow developers to correctly control the temporal behavior of application, i.e., how it will behave in real-world time. A real-time edition of Java must therefore provide some semantic JVM enhancements and a new API set appropriate for real-time applications. It is not surprising that the main obstacle in achieving real-time characteristics for Java is its garbage collector. A real-time garbage collector became a revolutionary and central component of Sun’s recently-released Java real-time edition RTS 1.0, although its first implementation does not include one (it is expected in the next release). Java RTS addresses other issues, making strong deterministic guarantees for thread scheduling, synchronization overhead, lock queuing order, class initialization, and maximum interrupt response latency. Java RTS is intended only for suitable underlying operating systems, which means that only a real-time operating system, such as QNX, is appropriate for implementing the JVM.


Realtime Specification for Java 2.0

Specs

  • Realtime Specification for Java 2.0 (RTSJ)
  • Author: Multiple, Aicas
  • May 2006 – June 2017

Resources

Synopsis

The goal of the Real-Time Specification for Java (RTSJ) is to support the use of Java technology in embedded and realtime systems. It provides a specification for refining the Java Language Specification and the Java Virtual Machine Specification and for providing an extended Application Programming Interface that facilitates the creation, verification, analysis, execution, and management of realtime Java programs such as control and sensor applications. The Java Virtual Machine and the Java Language were conceived as a portable environment for desktop and server applications. The emphasis has been on throughput and responsiveness. These are characteristics obtainable with time-sharing systems. For this conventional Java environment, it is more important that each task makes progress, than that a particular task completes within a predefined time slot. In a realtime system, the system tries to schedule the most critical task that is ready to run first. This task runs either until it is finished, or it needs to wait for some event or data, or a more critical task is released or a more critical task becomes schedulable after waiting for its event or data.


RTSJ Compatible VMs for Java

Specs

  • Realtime Specification for Java 2.0 (RTSJ)
  • Author: Ales Plsek
  • June 2009

Resources

Synopsis

Although real-time Java is becoming well known, the specific Virtual Machines implementing its functionalities are still known only to the community. There is no list of VMs supporting real-time features, furthermore, every VM is implementing a different subset of RTSJ. Therefore, I am posting a list of RTSJ-compatible VMs that are available up to this date (sorted by first release date).

Furthermore, other real-time, Java-like platforms have been developed, either commercial or academic projects. Usually, these VMs are not fully compliant with RTSJ.


Other Resources

  • Real-Time Java for the Enterprise
    • “Java, the language, and the Java Enterprise Edition platform have proved to be very popular for the development of enterprise applications. The ease-of-development, performance and reliability all make Java extremely attractive to developers. However, the Java platform does not support real-time applications, and even running a Java application on a real-time operating system will not make the application deterministic.”
  • Real-Time Java for Latency Critical Banking Applications
  • Exploit real-time Java’s unique features
    • “Real-time Java is a set of enhancements to the Java language that provide applications with a degree of real-time performance that exceeds that of standard Java technology. Real-time performance differs from traditional throughput performance, which is typically a measurement of the total number of instructions, tasks, or work that can be done over a fixed amount of time. Real-time performance focuses on the time an application requires to respond to external stimuli without exceeding given time constraints. In the case of hard real-time systems, such constraints must never be exceeded; softreal-time systems have a higher tolerance for violations. Real-time performance requires that the application itself gain control of the processor so that it can respond to stimuli, and that while responding to the stimuli the application’s code is not blocked from execution by competing processes within the virtual machine. Real-time Java delivers responsiveness previously unmet in Java applications.”

Realtime Infrastructure Services

  • Realtime API Infrastructure – Realtime API infrastructure specifically allows developers to build realtime data push into their existing APIs.  Typically, you would not need to modify your existing API contracts, as the streaming server would serve as a proxy. The proxy design allows these services to fit nicely within an API stack. This means it can inherit other facilities from your REST API, such as authentication, logging, throttling, etc. It can be combined with an API management system.  In the case of WebSocket messages being proxied out as HTTP requests, the messages may be handled statelessly by the backend. Messages from a single connection can even be load balanced across a set of backend instances.
    • Fanout/Pushpin – Fanout is a real-time API development kit that helps you push data to connected devices easily. Fanout is a cross between a reverse proxy and a message broker. Pushpin is the open source version.
    • Streamdata.io – Streamdata.io a SaaS API proxy tool that converts standard API requests into a streaming API. In other words, it provides a proxy as a service for any HTTP API by polling and acting as a streaming API.
    • LiveResource – LiveResource is a protocol specification and JavaScript reference library for receiving live updates of web resources. It has the following principles:
  • Realtime Application Infrastructure – Realtime app infrastructure sends data to browsers and clients. It typically uses pub/sub messaging, webhooks, and/or websockets — and is separate from an application or service’s main API.
    • Firebase – Firebase is a BaaS (Backend-as-a-Service) that allows developers to create web applications with no server-side programming required.
    • Pubnub – PubNub is a programmable Data Stream Network (DSN) and realtime infrastructure-as-a-service (IaaS) company. Primarily, they are a messaging solution hosted on a cloud service that allows developers to publish data instantly to one or multiple devices.
    • Pusher – Pusher is a hosted service that allows developers to add realtime bi-directional functionality via WebSockets (with HTTP-based fallbacks) to the web and mobile apps.
    • Ably – Ably is a realtime data delivery platform that provides creators the tools to create, deliver, and manage projects. Their main realtime functionality consists of pub/sub, presence, authentication, encryption, and connection state recovery.

Spotlight Article: API Eventing Is The Next Big Opportunity For API Providers by James Higginbotham

In this article, James Higginbotham outlines 5 reasons why your product’s API should support events.   He discusses this in the context of ‘API Eventing’, whereby APIs become event-driven.

For the last decade, modern web APIs have grown from solutions like Flickr, to robust platforms that generate new business models. Throughout this period of growth, most APIs have been limited to request-response over HTTP. We are now seeing a move back to eventing with the popularity of webhooks to connect SaaS solutions, the introduction of technologies such as Kafka to drive internal messaging, and the need for integrating IoT devices.

API eventing completely changes the way API consumers interact with our APIs, creating new possibilities that request-response cannot. Let’s examine the driving factors contributing to the rise of API eventing in greater detail, along with the opportunities that may inspire you to consider adding API event support to your API.

Full Article

Getting Started with Building Realtime API Infrastructure

How companies are adding realtime capabilities to their products and building realtime APIs

Mirroring the rise of API-driven applications, realtime is becoming an emerging, omnipresent force in modern application development. It is powering instant messaging, live sports feeds, geolocation, big data, and social feeds. But, what is realtime and what does it really mean? What types of software and technology are powering this industry? Let’s dive into it.

What Is Realtime?

For the more technical audience, realtime traditionally describes realtime computing, whereby “hardware and software systems are subject to a realtime constraint, for example from event to system response” (Source). For this article, we’re framing realtime from the perspective of an end-user: the perception that an event or action happens sufficiently quickly to be perceived as nearly instantaneous.

Moreover, realtime could be defined in a more relative temporal sense. It could mean that a change in A synchronizes with a change in B. Or, it could mean that a change in A immediately triggers a change in B. Or… it could mean that A tells B that something changed, yet B does nothing. Or… does it mean that A tells everyone something changed, but doesn’t care who listens?

Let’s dig a bit deeper. Realtime does not necessarily mean that something is updated instantly (in fact, there’s no singular definition of “instantly”). So, let’s not focus on the effect, but rather the mechanism. Realtime is about pushing data as fast as possible — it is automated, synchronous, and bi-directional communication between endpoints at a speed within a few hundred milliseconds. 

  • Synchronous means that both endpoints have access to data at the same time.
  • Bi-directional means that data can be sent in either direction.
  • Endpoints are senders or receivers of data (phone, tablet, server).
  • A few hundred milliseconds is a somewhat arbitrary metric since data cannot be delivered instantly, but it most closely aligns to what humans perceive as realtime (Robert Miller proved this in 1986).

With this definition and its caveats in mind, let’s explore the concept of pushing data.

Data Push

We’ll start by contrasting data push with “request-response.” Request-response is the most fundamental way that computer systems communicate. Computer A sends a request for something from Computer B, and Computer B responds with an answer. In other words, you can open up a browser and type “reddit.com.” The browser sends a request to Reddit’s servers and they respond with the web page.

Request-Response vs Evented APIs

In a data push model, data is pushed to a user’s device rather than pulled (requested) by the user. For example, modern push email allows users to receive email messages without having to check manually. Similarly, we can examine data push in a more continuous sense, whereby data is continuously broadcasted. Anyone who has access to a particular channel or frequency can receive that data and decide what to do with it.

Moreover, there are a few ways that data push/streaming is currently achieved:

HTTP Streaming

HTTP Streaming

HTTP streaming provides a long-lived connection for instant and continuous data push. You get the familiarity of HTTP with the performance of WebSockets. The client sends a request to the server and the server holds the response open for an indefinite length. This connection will stay open until a client closes it or a server side-side event occurs. If there is no new data to push, the application will send a series of keep-alive ticks so the connection doesn’t close.

Websockets

HTTP Web Sockets

WebSockets provide a long-lived connection for exchanging messages between client and server. Messages may flow in either direction for full-duplex communication. This bi-directional connection is established through a WebSocket handshake. Just like in HTTP Streaming and HTTP Long-Polling, the client sends a regular HTTP request to the server first. If the server agrees to the connection, the HTTP connection is replaced with a WebSocket connection.

Webhooks

Webhooks

Webhooks are a simple way of sending data between servers. No long-lived connections are needed. The sender makes an HTTP request to the receiver when there is data to push. A WebHook registers or “hooks” to a callback URL and will notify you anytime an event has occurred. You register this URL in advance and when an event happens, the server sends a HTTP POST request with an Event Object to the callback URL. This event object contains the new data that will be pushed to the callback URL. You might use a WebHook if you want to receive notifications about certain topics. It could also be used to notify you whenever a user changes or updates their profile.

HTTP Long-Polling

HTTP Long Polling

HTTP long-polling provides a long-lived connection for instant data push. It is the easiest mechanism to consume and also the easiest to make reliable. This technique provides a long-lived connection for instant data push. The server holds the request open until new data or a timeout occurs. Most send a timeout after 30 to 120 seconds, it depends on how the API was setup. After the client receives a response (whether that be from new data or a timeout), the client will send another request and this is repeated continuously.

Is pushing data hard? Yes, it is, especially at scale (ex. pushing updates to millions of phones simultaneously). To meet this demand, an entire realtime industry has emerged, which we’ll define as Realtime Infrastructure as Service (Realtime IaaS).

Realtime Libraries

Here is a compilation of resources that are available for developers to build realtime applications based on specific languages / frameworks:

Realtime Infrastructure as a Service

According to Gartner, “Infrastructure as a service (IaaS) is a standardized, highly automated offering, where compute resources, complemented by storage and networking capabilities are owned and hosted by a service provider and offered to customers on-demand. Customers are able to self-provision this infrastructure, using a Web-based graphical user interface that serves as an IT operations management console for the overall environment. API access to the infrastructure may also be offered as an option.”

We often here PaaS (Platform as a Service) and SaaS (Software as a Service), so how are they different than IaaS?

  • Infrastructure as a Service (IaaS): hardware is provided by an external provider and managed for you.
  • Platform as a Service (PaaS): both hardware and your operating system layer are managed for you.
  • Software as a Service (SaaS): an application layer is provided for the platform and infrastructure (which is managed for you).

To power realtime, applications require a carefully architected system of servers, APIs, load balancers, etc. Instead of building these systems in-house, organizations are finding it more cost-effective and resource-efficient to purchase much of this systemic infrastructure and then drive it in-house. These systems, therefore, are not just IaaS, but typically provide both a platform and software layer to help with management. Foundationally speaking, their core benefit is that they provide realtime infrastructure, whether you host it internally or rely on managed instance

It all comes down to the simple truth that realtime is hard for a number of reasons:

  • Customer Uptime Demand – Customers that depend on realtime updates will immediately notice when your network is not performant.
  • Horizontal Scalability – You must be able to handle volatile and massive loads on your system or risk downtime. This is typically achieved through clever horizontal scalability and systems that are able to manage millions of simultaneous connections.
  • Architectural Complexity – Maintaining a performant realtime system is not only complex, but it requires extensive experience and expertise. This is expensive to buy, especially in today’s high demand engineering market.
  • Contingencies – Inevitably, your system will experience some downtime, whether due to an anticipated load spike or a newly released feature. It is important, therefore, to have multiple uptime contingencies in place to make sure that the system knows what to do, should your primary realtime mechanism fail to perform.
  • Queuing – When you’re sending a lot of data, then you likely need an intermediate queuing mechanism to ensure that your backend processes are not overburdened with increased message loads.

Realtime Application IaaS

Realtime app infrastructure sends data to browsers and clients. It typically uses pub/sub messaging, webhooks, and/or websockets — and is separate from an application or service’s main API. These solutions are best for organizations that are looking for realtime messaging without the need to build their own realtime APIs.

Pub-Subscribe PubSub Pattern for Realtime API

These systems also have more well-built platform/software management tools on top of their infrastructure offerings. For instance, the leading providers have built-in configuration tools like access controls, event delegation, debugging tools, and channel configuration.

Benefits of Realtime App IaaS

  • Speed – typically explicitly designed to deliver data with low latencies to end-user devices, including smartphones, tablets, browsers, and laptops.
  • Multiple SDKs for easier integration.
  • Uses globally distributed realtime data delivery platforms.
  • Multiple protocol adapters.
  • Well-tested in production environments.
  • Keeps internal configuration to a minimum.

Use Cases

While some of the platforms out there function differently, here are some of the most typical use cases:

  • Realtime Chat – In a microservice environment, a realtime API proxy makes it easy to listen for instant updates from other microservices without the need for a centralized message broker. Each microservice gets its own proxy instance, and microservices communicate with each other via your organization’s own API contracts rather than a vendor-specific mechanism.
  • IoT Device Control – Securely monitor, control, provision and stream data between Internet-connected devices.
  • Geotracking / Mapping Realtime Updates – Integrates with other realtime APIs like (Google Maps) to construct rich realtime updates.
  • Multiplayer Game Synchronization – Synchronize communications amongst multiple simultaneous players to keep play fluid.

Solutions

Here are some realtime application IaaS providers (managed) to check out for further learning: PubNubPusher, and Ably.

Realtime API IaaS for API Development

Realtime API infrastructure specifically allows developers to build realtime data push into their existing APIs. Typically, you would not need to modify your existing API contracts, as the streaming server would serve as a proxy. The proxy design allows these services to fit nicely within an API stack. This means it can inherit other facilities from your REST API, such as authentication, logging, throttling, etc and, consequently, it can be easily combined with an API management system. In the case of WebSocket messages being proxied out as HTTP requests, the messages may be handled statelessly by the backend. Messages from a single connection can even be load balanced across a set of backend instances.

Realtime API Infrastructure as a service IaaS Proxy

All in all, realtime API IaaS is used for API development, specifically geared for organizations that need to build highly-performant realtime APIs like Slack, Instagram, Google, etc. All of these orgs build and manage their infrastructure internally, so the IaaS offering can be thought of as a way to extend these capabilities to organizations that lack the resources and technical expertise to build a realtime API from scratch.

Benefits of Realtime API IaaS

  • Custom build an internal API.
  • Works with existing API management systems.
  • Does not lock you into a particular tech stack.
  • Provides realtime capabilities throughout entire stack.
  • Usually proxy-based, with pub/sub or polling.
  • Add realtime to any API, no matter what backend language or database.
  • Cloud or self-hosted API infrastructure.
  • It can inherit facilities from your REST API, such as authentication, logging, throttling.

Use Cases

While some of the platforms out there function differently, here are some of the most typical use cases:

  • API development – As we’ve discussed, you can build custom realtime APIs on top of your existing API infrastructure.
  • Microservices – In a microservice environment, a realtime API proxy makes it easy to listen for instant updates from other microservices without the need for a centralized message broker. Each microservice gets its own proxy instance, and microservices communicate with each other via your organization’s own API contracts rather than a vendor-specific mechanism.
  • Message queue – If you have a lot of data to push, you may want to introduce an intermediate message queue. This way, backend processes can publish data once to the message queue, and the queue can relay the data via an adapter to one or more proxy instances. The realtime proxy is able to forward subscription information to such adapters, so that messages can be sent only to the proxy instances that have subscribers for a given channel.
  • API management – It’s possible to combine an API management system with a realtime proxy. Most API management systems work as proxy servers as well, which means all you need to do is chain the proxies together. Place the realtime proxy in the front, so that the API management system isn’t subjected to long-lived connections. Also, the realtime proxy can typically translate WebSocket protocol to HTTP, allowing the API management system to operate on the translated data.
  • Large scale CDN performance – Since realtime proxy instances don’t talk to each other, and message delivery can be tiered, this means the realtime proxy instances can be geographically distributed to create a realtime push CDN. Clients can connect to the nearest regional edge server, and events can radiate out from a data source to the edges.

Solutions

Here are some realtime API IaaS providers (managed/open source) to check out for further learning: Fanout/PushpinStreamdata.io, and LiveResource.

Conclusion

Realtime is becoming an emerging, omnipresent force in modern application development. It is not only a product differentiator, but is often sufficient for product success. It has accelerated the proliferation of widely-used apps like Google Maps, Lyft, and Slack. Whether you’re looking to build your own API from scratch or build on top of an IaaS platform, realtime capabilities are increasingly becoming a requirement of the modern tech ecosystem.

Resource Spotlight: EventedAPI.org Spec by Sam Curren and Phillip J. Windley

This online resource is a unique way to frame a conceptual model for evented APIs.  Sam Curren and Phillip J. Windley discuss the fundamentals of evented APIs, how evented systems work, and a proposed protocol.

Events indicate something has happened. In this they differ from the request-response interaction style popular on the Web. Event-based systems are declarative whereas request-response systems are interrogatory. The difference between events (“this happened”) and requests (“will you do this?”) offers benefits in looser coupling of components as well as semantic encapsulation (see On Hierarchies and Networks for more detail).

APIs have become an economic imperative for many companies. But APIs based solely on request-response style interactions limit integrations to those where one system always knows what it wants from the other. The calling service must script the interaction and the APIs simply follow along.

We envision a world where applications integrate multiple products and services as equals based on event-driven interactions. Evented APIs, following the form described in this document, enable building such applications.

API Tutorials

Here, we’ve aggregated a list of API tutorials that provide the basic principles for building APIs.  These apply to both REST and realtime APIs.

Here are some of the top API resources to check out:

  • Programmable Web – Rich API content through their API University
  • Web API Design – “This e-book is a collection of design practices that we have developed in collaboration with some of the leading API teams around the world, as they craft their API strategy through a design workshop that we provide at Apigee.”
  • API Design Fundamentals – ‘The fundamental concept in any RESTful API is the resource. A resource is an object with a type, associated data, relationships to other resources, and a set of methods that operate on it. It is similar to an object instance in an object-oriented programming language, with the important difference that only a few standard methods are defined for the resource (corresponding to the standard HTTP GET, POST, PUT and DELETE methods), while an object instance typically has many methods.’

From Nordic APIS:

Zapier’s Introduction to APIs

Zapier has done a great job putting together a course introducing APIs. It is perfect for those just starting their API journey and covers protocols, data formats, API design, authentication, real-time communication, and implementation.

Entrepreneurship and APIs

If you are looking for an easy read about how important APIs are in entrepreneurial endeavors, I wrote an explanation on the topic a few weeks back. It briefly introduces some important business benefits of APIs, and why upcoming business builders should be learning and using this technology.

API Academy

API Academy provides free online lessons and in-person consulting services that cover essential API techniques. This useful resource provides business managers, interface designers and enterprise architects with some important knowledge. The growing repository is one you will want to revisit every so often.

API Evangelist’s Whitepapers

Kin Lane’s white papers on the basics of APIs, their history, and how to deploy and manage them are a useful collection of resources. He has also just released one on API design that is worth checking out.

Additional Resources

Research Library: The Experience API—Liberating Learning Design. Peter Berking, Steve Foreman, Jason Haag, Craig Wiggins. Research report. (Paid membership required for access.)

Online Events Archive: Learning Platform Strategies: LMS, LRS, or Both? Robert Gadd, Craig Wiggins. Handout and recording (1:16). (Paid membership required for access.)

Conference Archive: The ABC’s of xAPI: Lessons Learned and Shared. Robert Gadd, Dave Smelser. Handout, video (59:18).

Online Events Archive: LRSs: What You Need to Know Now. Rob Houck, Megan Torrance. Handout, recording (1:14:53). (Paid membership required for access.)

Conference Archive: Break Out of the Web Browser Box with the Experience API.David Smith. Handout.

 

Article Spotlight: 5 Protocols For Event-Driven API Architectures by Kristopher Sandoval

In this article, Kristopher Sandoval highlights the five most common event-driven methods for data push.  These methods all have their pros and cons, and work best based on your particular use cases.

The internet is a system of communication, and as such, the relationship between client and server, as well as server to server, is one of the most oft-discussed and hotly contested concepts. event-driven architecture is a methodology of defining these relationships, and creating systems within a specific set of relationships that allow for extensive functionality.

In this piece, we’re going to discuss 5 common event-driven methods — WebSocketsWebHooksREST HooksPub-Sub, and Server Sent Events. We’ll define what they fundamentally are and do, and how API providers go about using them. Additionally, we’ll provide some pros and cons on each to make choosing a solution for your platform easy and intuitive.

Full Article

Realtime API Best Practices

Performance Best Practices

  • Be cognizant of your API’s rate limiting.  Make sure you set reasonable rate limits that are forgiving when necessary.
  • Avoid storing large binary objects, like images, within the data model. Instead, you can link to files stored separately in Google Drive, or on an external server.
  • Adapt a dynamic realtime model that supports HTTP streaming, HTTP long-polling, and WebSockets
  • Standardize a protocol
  • Make realtime push behavior delegable – the reason there isn’t a realtime push CDN yet is because the standards and practices necessary for delegating to a third party in a transparent way are not yet established.
  • As your API scales, a multi-tiered architecture will become inevitable, so make sure you have sufficient plans for scale.
  • Make sure you have multiple layers of redundancy and reliability to maintain performance, should something go wrong.

Challenges

In push architectures, one of the main challenges is delivering data reliably to receivers. There are many reasons for this:

  • Most push architectures (including those developed by our company) use the publish-subscribe messaging pattern, which is unreliable.
  • TCP’s built-in reliability is not enough to ensure delivery, as modern network sessions span multiple connections.
  • Receivers can’t tell the difference between data loss and intentional silence.
  • There is no one size fits all answer.

The last point trips up developers new to this problem space, who may wish for push systems to provide “guaranteed delivery.” If only it were that simple. Like many challenges in computer science, there isn’t a best answer, just trade-offs you are willing to accept.

Below we’ll go over the various issues and recommended practices around reliable push.

Publish-subscribe is unreliable by design

If you rely on a publish-subscribe broker as your source of truth then you’ll most likely end up with an application that loses data. Publishers might crash before having a chance to publish, and brokers don’t guarantee delivery anyway.

The only way a publish-subscribe broker could conceivably deliver data 100% reliably would be to do one of two things:

  1. Implement publisher back pressure based on the slowest subscriber.
  2. Store all published messages in durable storage for all of time.

Both of these options are terrible, so in general nobody does them. Instead, what you see are various degrees of best-effort behavior, for example large queues, or queues with a time limit (e.g. messages deliverable for N hours/days).

This isn’t to say publish-subscribe is unsuitable for push; in fact it’s an essential tool in your toolbox. Just know that it’s only one piece of the puzzle. The ZeroMQ guide has a section on publish-subscribethat’s worth reading even if you’re not using ZeroMQ.

TCP is about flow control, not reliability

In the modern world of mobile devices and cloud services, a single user session can easily span multiple client/server IP address pairs. TCP will retransmit data as necessary within a single connection, but it won’t retransmit across connections, for example if a client has to reconnect. Further, even if IP addresses are stable, TCP doesn’t attempt retransmissions forever. It tries really hard for awhile but will eventually give up if a peer is unresponsive.

In practice, this means TCP alone isn’t enough for reliable data transfer, and you’ll need to layer a reliable protocol on top of it.

If you learned long ago that TCP is for reliable communication (compared to, say, UDP), then you may be confused by this and wonder why developers continue to build systems using TCP. Well, TCP provides other useful features, such as back pressure, ordered delivery, and payloads of arbitrary size, so it is still an incredibly useful protocol even if we can’t depend on it for reliable transmission.

Error handling on the receiver

With request/response interactions, you can retry if a request fails, or just bubble errors up to the UI. With push, lost data looks about the same as no data, and users are left wondering why their screens aren’t updating.

What’s really obnoxious about this problem is that it’s not enough to just throw an error when a connection to the server is lost. You can lose data even when a connection seems to be working fine, due to some deeper failure within the server. This means the receiver usually cannot rely on the existence of a connection or subscription to be very meaningful, and will need to discover errors some other way.

Reliable transmission fundamentals

Before we get into the common practices, let’s go over some basics. Reliably exchanging data over a network requires two things:

  1. An ability to retransmit data, potentially for a long time if loss is not tolerable.
  2. An entity responsible for initiating a retransmission.

For example, when a mail server sends email to another mail server using SMTP, the sending mail server owns the data to be retransmitted and also acts as the responsible entity.

The entity responsible for initiating a retransmission doesn’t have to be the sender, though. For example, in web architectures, it’s common for a server to attempt to push data to a receiver, but if that fails then it’s up to the receiver to query the server for the missed data. In this case the receiver is the responsible entity.

Before you can build a reliable system, you need to determine whether the sender or receiver should be the responsible entity. This usually comes down to which side should care more about the transmission.

Alright, so how can applications ensure data is reliably delivered?

Use a regular database as a source of truth. If pushed data is important, the first thing you should do is write it to durable storage (on disk, with no automatic expiration), before kicking off any push mechanisms. This way if there’s a problem during delivery, the data can later be recovered.

The receiver should be the responsible entity. Receivers usually come and go, and it makes more sense for receivers to keep track of what they need rather than for servers to keep track of what has been sent.

Have a way to sync with the server. Receivers should be able to ask the server for new data, independent of any realtime push mechanisms. This way, publish workers can crash, queues can max out, and connections can get dropped, yet receivers can always catch up by making requests for updates.

Architect your system initially without push. Related to the previous recommendations, if you build a system where your data lives in durable storage, and receivers have a way to ask for incremental updates, then it will be easy to add a push layer on top. This may seem like a boring approach, but boring works.

Consider sending hints. This is where you push indications of new data rather than the actual data. Receivers react to hints by making requests for updates. See Andyet’s article about this approach. Hints are straightforward and work well if there aren’t too many recipients for the same data.

Include sequencing information. If data may arrive from potentially two sources (push subscription or request for updates), or data is a stream of deltas, then receivers will need a way to detect for out-of-sequence data. This can be done by including a sequence or version ID in the data payloads. If there is a sequencing problem when receiving a stream of deltas, then the receiver will need to make a request to the server for updates.

Periodically sync with the server. If data is sent infrequently, then receivers may want to periodically check in with the server to ensure nothing has been missed. For a typical web app, this interval could be something like a few minutes.

 


AsyncAPI Specification

AsyncAPI Specification codifies and standardizes the documentation and definitions of asynchronous APIs.

According to the AsyncAPI site, “the  AsyncAPI specification allows you to create machine-readable definitions of your asynchronous APIs. It’s protocol-agnostic, so you can use it for APIs that work over MQTT, AMQP, WebSockets, STOMP, etc. The specification is heavily inspired on OpenAPI (fka Swagger) and it’s designed to maintain as much compatibility as possible with it.”

The AsyncAPI Specification defines a set of files required to describe such an API, which can be used to create utilities, such as documentation, integration and/or testing tools.


REST Hooks

Codified by the team at ZapierREST Hooks (RESTful WebHooks) is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource.  REST Hooks support subscription, notification, and publication through a RESTful interface. This retains the RESTful patterns by using HTTP GET, PUT, POST and DELETE to act on subscription, notification, and publication resources.  In other words, the REST Hook pattern adheres to standard REST definitions

There are 4 primary components for creating REST Hooks:

  1. Create a subscription – the webhook needs to be tied to a subscriber URL in order to escape polling
  2. Send the hook – the API sends the data via a POST
  3. Unsubscribing – a delete call is made to unsubscribe
  4. Setting up a global URL – you can create a polling URL to create a permanent location from where to draw data