Author Archive

Edge Computing —A Beginner’s Guide

Learn the basics of edge computing and how it is transforming the realtime landscape

Machine Pulse

The Edge

The ‘edge’ refers to computing infrastructure that exists close to the origin sources of data. It is distributed IT architecture and infrastructure where data is processed at the periphery of the network, as close to the originating source as possible.

Edge computing is a method of optimizing cloudcomputing systems by performing data processing at theedge of the network, near the source of the data.

OAS

Living on the Edge

A series of gateway servers sit outside your primary cloud environment, allowing for more localized data processing.

Examples of edge computing can be found throughout our everyday lives — we just may not notice them.

Industrial Internet of Things (IIoT)

  • Wind turbines
  • Magnetic resonance (MR) scanner
  • Undersea blowout preventers
  • Industrial controllers such as SCADA systems
  • Automated industrial machines
  • Smart power grid technology
  • Smart streetlights

Internet of Things (IoT)

  • Motor vehicles (Cars and trucks)
  • Mobile devices
  • Traffic lights
  • Thermostats
  • Home appliances
TechTarget

Edge Computing Benefits

Edge computing allows for the clear scoping of computing resources for optimal processing.

  1. Time-sensitive data can be processed at the point of origin by a localized processor (a device that has its own computing ability).
  2. Intermediary servers can be used to process data in close geographical proximity to the source (this assumes that intermediate latency is okay, though realtime decisions should be made as close to the origin as possible).
  3. Cloud servers can be used to process less time sensitive data or to store data for the longterm. With IoT, you’ll see this manifest in analytics dashboards.
  4. Edge application services significantly decrease the volumes of data that must be moved, the consequent traffic, and the distance the data must travel, thereby reducing transmission costs, shrinking latency, and improving quality of service(QoS) (source).
  5. Edge computing removes a major bottleneck and potential point of failure by de-emphasizing the dependency on the core computing environment.
  6. Security improves as encrypted data is checked as it passes through protected firewalls and other security points, where viruses, compromised data, and active hackers can be caught early on (source).
  7. The edge augments scalability by logically grouping CPU capabilities as needed, saving costs on realtime data transmission.

Why the Edge

Transmitting massive amounts of data is expensive and taxing on network resources. Edge computing allows you to process data near the source and only send relevant data over the network to an intermediate data processor.

For example, a smart refrigerator does not need to continually send internal temperature data back to a cloud analytics dashboard. Rather, it can be configured to only send data when the temperature has changed beyond a particular point; or, it could be polled to send data only when the dashboard is loaded. Similarly, an IoT security camera could only need to send data back to your device when it detects motion or when you explicitly toggle a live data feed.

Devise Relationship Management (DRM)

To manage edge devices, device relationship management (DRM) refers to the monitoring and maintenance of complex, intelligent, and interconnected equipment over the internet. DRM is specifically designed to interface with the microprocessors and local software in IoT devices.

Device relationship management (DRM) is enterprise software that enables the monitoring, managing, and servicing of intelligent devices over the Internet.

TechTarget

The Fog

Between the edge and cloud is the fog layer, which helps bridge the connections between edge devices and cloud data centers. According to Matt Newton of Opto 22:

Fog computing pushes intelligence down to the local area network level of network architecture, processing data in a fog node or IoT gateway.

Edge computing pushes the intelligence, processing power and communication capabilities of an edge gateway or appliance directly into devices like programmable automation controllers (PACs).

Energomonitor

Edge and Realtime

Sensors and remotely deployed devices demand realtime processing. A centralized cloud system is often too slow for this, especially when decisions need to be made in microseconds. This is especially true for IoT devices in regions or locations with poor connectivity.

However, sometimes realtime capabilities demand cloud processing. For example, lets say data consumed by remote tornado weather monitors needs to be sent in realtime to massive supercomputers.

This is where realtime infrastructure comes into play to help enable those data transactions.

PubNub.com

By 2020, 50% of Managed APIs Projected to be Event-Driven

The proliferation of event-driven, realtime APIs fueled by big data, IoT, and consumer expectations

According to Mark O’Neill and Paolo Malinverno of Gartner, 50% of managed APIs will support event-driven IT by 2020 (2017 Report).  These event-driven APIs will not necessarily replace RESTful request-response architectures, but will become necessary supplements to expand an organization’s functional offerings and overall performance.

In another 2017 IoT report, Gartner projects “8.4 billion connected devices, up 31% from 2016, and will reach 20.4 billion by 2020. Total spending on endpoint infrastructure and services will reach almost $2 trillion in 2017.”

So, what’s driving this evolution? “Realtime” is becoming an omnipresent force in the modern tech stack. As consumers demand faster experiences and more instantaneous data transactions, companies are increasingly investing in product infrastructure that accelerates these transactions. Though we’ve seen APIs become an economic and technological imperative, they are typically based on request-response style interactions, which limits their scope and effectiveness in the realtime arena.

Request-Response vs Event-Driven APIs

At its core, request–response is a message exchange pattern in which a requestor sends a request message to a replier system. The replier system receives and processes the request, and if all goes well, it returns a message in response. While this exchange format works well for more structured requests, it limits integrations to those where the expectant system has a clear idea what it wants from the other. These request-response style APIs, therefore, must follow the interaction script from the calling service.

Request-Response vs Event-Driven Realtime APIs

In an event-driven architecture, applications integrate multiple services and products as equals based on event-driven interactions. These interactions are driven by event emitters, event consumers, and event channels, whereby the events, themselves, are typically significant ‘changes in state’ that are produced, published, propagated, detected, or consumed. This architectural pattern supports loose coupling amongst software components and services. The advantage is that an event emitter does not need to know the state of the consumer, who the consumer is, or how the event will be processed (if at all). It is a mechanism of pushing data through a persistent stream.

The $195 Billion IoT Market

The proliferation and ‘smartening’ of IoT-driven devices is projected to reach a market cap exceeding $195 billion in 2023, according to analysts at ReportsnReports. From a market of $16 billion in 2016, this growth is mainly fueled by the increasingly ubiquitous manufacturing of smarter in-home, mobile, and transportation devices — and the need to capture that data and enhance communication infrastructure.

The smarter devices become, the more data they need to make complex, realtime decisions. Sensors and external data gathering implements are becoming an essential catalyst for IoT industry growth. The accuracy of sensors and actuators that measure geospatial proximity, acceleration, temperature, and motion will separate the industry leaders from the laggards.

IoT_realtime API

Postscapes

Taking a deeper dive into the actual core components, like semiconductors, Gartner forecasts a $45 billion IoT-driven semiconductor market by 2020, with consumer IoT taking the lion’s share and the automotive industry (including self-driving vehicles) taking second.

Data & Business Intelligence

The goal of a truly interconnected tech ecosystem will also mirror equal growth in data and business intelligence. The more things are interconnected, the more companies will need to gather data, push remote updates, and control devices in the field. Hence, remote communication needs to be reliable, data needs to be accurate, and the ability to extract meaningful information from big data becomes paramount.

In a 2015 report by Seagate, 25% of all data will need to be processed and generated in realtime by 2025 out of a total of 160 Zettabytes.

rise of realtime data

Event-Driven API Mechanisms

If you’re looking to understand the web infrastructure behind realtime, then let’s explore some of its basic components. A more thorough analysis can be found in Getting Started with Realtime API Infrastructure.

Realtime is all about pushing data. 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.

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

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 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 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.

And, of course, there is the infrastructure behind it all.

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.

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.

Main Take-Aways

IoT, big data, and consumer expectations are fueling the proliferation of event-driven / realtime APIs. One of the greatest challenges facing engineers over the next few years will be constructing scalable, fault-tolerant event-driven architectures at scale.  This is why we are seeing companies spend more than $2 trillion in 2017 to support event-driven endpoints and infrastructure.

While RESTful architectures will remain a necessity, it is important for organizations to understand and plan for event-driven systems — which add a new dimension of realtime API infrastructure complexity.

The 6 Step Build vs Buy Model for Developers

Defining a process for objectively selecting homegrown or purchased solutions

For almost every functional or architectural application component, there are a plethora of ‘as a service’ offerings. We see infrastructure as a service (IaaS), backend as a service (BaaS), SaaS, PaaS.. and a new ‘aaS’ seems to be added daily.

What do all these services have in common? Well, they aspirationally promise to give you, the engineer, (1) more freedom to focus on your core product, (2) faster time to market, and (3) production-ready solutions for complex and repeatable engineering operations.

Sometimes this is case. Sometimes it isn’t. This purpose of this guide is to provide a rational set of objective criteria to assess whether you should build or buy a particular service.

What is build? What is buy?

Build does not necessarily mean that you are making something from scratch. It means that you are combining custom code, open source libraries, and individual/community expertise to construct a solution for your use case. This solution is something that you will design, build, run, maintain, and scale internally.

On the other hand, buy does not necessarily mean that you are purchasing an end-to-end, out-of-the-box solution for your use case. It more accurately represents the purchase of a defined service that adds near-immediate value to your use case. Typically, the viability of the service itself will be guaranteed by the seller and you will not need to design and build the service itself. However, depending on the type of service purchased, you may choose to run and scale it internally. Generally, you will offload the running, maintenance, and scalability to the seller.

The Developer Mind

Before we continue, let’s reset our frame of mind.

Many developers have strong egos, and that’s generally an empowering attribute. Strong egos give devs the confidence to power through complex obstacles, focus for days and weeks at a time, and cultivate entirely new industries. However, there’s a fine line between reasonable and unreasonable confidence.

“I can build ____ in ____ days!”
“Ha! I can build a better ____ in a weekend!”
“This is so expensive. I’m just going to build it.”

We frequently see and hear these comments on dev forums, aggregators like Reddit and HackerNews, and in our day-to-day interactions. If we don’t say it, then some of us probably think it from time to time. Hey, sometimes we’re probably right, but often times, our initial ego-driven reaction distances us from the objective criteria we apply to our general practice of programming.

When assessing what to build vs buy, or which ratio we choose, it is critical that we reset our frame of mind and approach our solutioning as open-minded and objectively as possible. Excluding the purists, no one cares if we were able to build our product from scratch or if we cleverly integrated a series of purchased solutions together. What people care about is if our product works and delivers exceptional value to customers.

With the build vs buy decision-making process, we will answer the question: “How do we deliver exceptional value to our customers quickly, efficiently, and prudently?”

Build vs Buy Decision-Making Model

build versus buy guide and process for developers to choose software

Step 1 – Identify and categorize your product’s functional scope

Your team has been tasked with building an ecommerce platform that allows users to upvote and downvote products. So, what are your product’s functional and architectural features?

Functional

  • Marketplace service
  • Voting service
  • Product display service
  • Inventory management service
  • Transaction service
  • Buyer, seller, and admin account management service
  • Search, filter, refine service

Architectural and Process

  • Databases
  • Servers
  • Load Balancers
  • Dev Environment / Version Control
  • Continuous Integration / Delivery Pipeline
  • REST / Realtime APIs
  • Frontend Framework
  • Deployment Controls / AB Testing

While these are not comprehensive feature sets, the important point is that there is a clear distinction between core product features (marketplace, voting), and necessary system & process architecture (server environment, CI/CD pipeline). There are features that are proprietary and unique to your product, and there are architectural features that are found in almost every modern application system.

Your job is to identify which of these features are proprietary to your platform and which are replicable proven solutions. To do this, ask the following questions:

  • What are the proprietary, core features that make my application unique?
  • What architectural services do I need for my platform scaffolding?
  • What is my ideal development pipeline going to look like?

Keep in mind, we are not solutioning yet or deciding what to build vs buy. We are identifying and categorizing our product’s functionality.

Step 2 – Define the scope of work and reconcile against constraints

Based on your feature categorization in step 1, it is time to define the scope of work to build each feature.

First, itemize and prioritize the detailed functionality for each feature:

  • What is the minimum functional scope for the feature to be viable?
  • What is the ideal functional scope for the feature?
  • Is this a feature I need now? Or can it wait?

Second, for each feature, answer the following build questions for the minimum and ideal functional scope:

  • How many developer resources do I have available to build this feature? Maintain this feature?
  • Can I harness any domain experts to help design this feature?
  • Has anyone on my team built this before?
  • How much time to design (A), build (B), test (C), deploy (D), maintain (E) this feature?
  • Will building this divert resources from something else?
  • Do I need to hire additional resources? If so, what is the cost breakdown?
  • What is the infrastructure cost to run this internally?

Third, for each core feature, answer the following buy questions for the minimum and ideal functional scope:

  • What is my monthly budget for this service?
  • How do I anticipate my budget changing over time?
  • Can I harness any domain experts to help me assess the best solution?
  • What developer resources do I have available to integrate and configure the solution?
  • If applicable, will I have the resources to self-host, run, maintain, and scale the service?

Step 3 – Solution divergence

Now we can get to the good stuff! In this step, we are not deciding what to build or buy; rather, we are aggregating an inventory of choices.

First, scour the interwebs, get referrals, and assess the solution ecosystem. Have other teams built this successfully? Have they bought it successfully? What are the horror and success stories?

Second, create a build vs buy comparison matrix. Make sure to note the monthly, infrastructure, and long-term maintenance costs. Note the total upfront and ongoing time needed for each build or buy solution (having build/buy hybrids are great too!).

Step 4 – Solution convergence

Start narrowing down your options.

Remember that buying does not mean out-of-the-box instant magic. There are always build costs associated with buying:

  • Sandboxing and initial technical vetting
  • Integration and setup
  • Configuration and fine tuning
  • Operational training and staff onboarding

Similarly, building does not necessarily mean that everything is made from scratch, but it does mean that you will assume the costs of ongoing maintenance, scaling, and debugging. You will also need to train staff and develop new operational processes.

Step 5 – Build or buy or both

Choose a primary and secondary solution option for each feature. This way, you will have a backup plan if the primary solution does not pan out. It is absolutely critical that you involve your team during the selection process and make the selection criteria transparent.

Step 6 – Develop guidelines for reassessment

The solution that you’ve selected for day 1 of your product will likely not fit your product at day 600. This is okay, but we must be able to anticipate and preempt any future scaling issues. To do this, set both quantitative and qualitative benchmarks for triggering a build vs buy scaling reassessment. For example, we’re confident that our current architectural solution allows us to handle up to 500k concurrent connections with ease, but our current growth model forecasts 2m connections in 8 months. When we start to near the 300k mark, then this will trigger another build vs buy assessment so we can preempt any issues at scale. This reassessment should include:

  • What have we learned about the needs of our product in the past X months?
  • What has been more difficult than anticipated? What has been easier?
  • How has our resource and knowledge pool shifted?
  • Have our product’s core competencies shifted?
  • Is there anything new and better out there?

Final Thoughts – Try It Your Way

Well, this looks like a lot of work. It may even take a day or multiple days to assess a feature. But realistically, when we take into account the full lifecycle of your product, a few upfront days can save you months and lots of money down the road. Those few days may also make or break your product.

Customize your build vs buy assessment process to meet your organization’s needs. Though a large enterprise is way different than a startup, the assessment metrics remain very similar. Add or remove metrics, codify a more refined process, or make your own from scratch.

Either way, it is important to remember that building a successful product is very hard, so don’t make it harder on yourself than necessary. Let your decision be driven by choosing the right solution for your product, rather than the right solution for you.

Spotlight Article: What do you mean by “Event-Driven”? by Martin Fowler

In his article, Martin Fowler discusses the meaning of ‘event-driven’ and all its nuances.  He tries to make sense of the various patterns that make up the event-driven landscape.

Towards the end of last year I attended a workshop with my colleagues in ThoughtWorks to discuss the nature of “event-driven” applications. Over the last few years we’ve been building lots of systems that make a lot of use of events, and they’ve been often praised, and often damned. Our North American office organized a summit, and ThoughtWorks senior developers from all over the world showed up to share ideas.

The biggest outcome of the summit was recognizing that when people talk about “events”, they actually mean some quite different things. So we spent a lot of time trying to tease out what some useful patterns might be. This note is a brief summary of the main ones we identified.

Full Article

.NET/C# Realtime Resources

This section highlights the realtime resources available for .NET / C# developers.


Realtime .NET/C# Libraries

SignalR: Incredibly simple real-time web for .NET  – ASP.NET SignalR is a library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. What is “real-time web” functionality? It’s the ability to have your server-side code push content to the connected clients as it happens, in real-time.

ASP.NET Core SignalR: Incredibly simple real-time web for ASP.NET Core  – ASP.NET Core SignalR is a new library for ASP.NET Core developers that makes it incredibly simple to add real-time web functionality to your applications. What is “real-time web” functionality? It’s the ability to have your server-side code push content to the connected clients as it happens, in real-time. You can watch an introductory presentation here – Introducing ASP.NET Core Sockets.  This project is part of ASP.NET Core. You can find samples, documentation and getting started instructions for ASP.NET Core at the Home repo.

Awesome Dotnet: A collection of awesome .NET libraries, tools, frameworks and software – A collection of awesome .NET libraries, tools, frameworks, and software.

.NET Websocket-Manager: Real-Time library for ASP .NET Core – This is an Asp .Net Core middleware that provides real-time functionality to .NET Core applications. To the core, it is a WebSocket middleware for Asp .Net Core with TypeScript / JavaScript client and .Net Core client that supports the client and the server invoking each others’ methods.

C# FirebaseDatabase.net: C# library for Firebase Realtime Database –  Simple wrapper on top of Firebase Realtime Database REST API. Among others it supports streaming API which you can use for realtime notifications. For Authenticating with Firebase checkout the Firebase Authentication library and related blog post .

Rocket.Chat: A Rocket.Chat realtime managed .Net driver and bot – A Rocket.Chat real-time, managed, .Net driver, and bot.

GTFS Realtime Bindings: .NET GTFS-realtime Language Bindings  – Provides .NET classes generated from the GTFS-realtime Protocol Buffer specification. These classes will allow you to parse a binary Protocol Buffer GTFS-realtime data feed into C# objects.

Spreads: Series and Panels for Real-time and Exploratory Analysis of Data Streams – Spreads is an ultra-fast library for complex event processing and time series manipulation. It could process tens of millions items per second per thread – historical and real-time data in the same fashion, which allows to build and test analytical systems on historical data and use the same code for processing real-time data.

OpenRA: Open Source real-time strategy game engine  – A Libre/Free Real Time Strategy game engine supporting early Westwood classics, such as Command & Conquer: Red Alert written in C# using SDL and OpenGL. Runs on Windows, Linux, *BSD and Mac OS X.

CompBench: Benchmark for native C# realtime compression libraries  – This is a tiny benchmark program I wrote a couple years ago for my personal use. It generates a few data files and feeds them to different compression libraries to measure compression ratio and speed.


How to add Real-time Data to your .NET Application

Specs

  • Author: Bitovi, Brian Moschel
  • April 2017

Resources

Synopsis

Web applications have increasingly turned to real-time data to provide more dynamic and useful features – for example chat, collaborative editing, and real-time analytics. This trend is evident in the .NET world. While .NET is great, real-time .NET is even better.

Similar to the popularity of AJAX leading to more single-page applications and fewer page refreshes, the recent addition of WebSockets and similar real-time protocols in mainstream browsers has lead to more real-time data connections and less “request data on page load and force the user to refresh if they want updated data” applications.

In this article, you’ll learn a simple way to add real-time functionality to your .NET application. The article will introduce two technologies — SignalR on the server and can-connect-signalr on the client — which make setting up real-time connections both simple and quick. We’ll show how to use both of these libraries by making a simple chat application.


Real-Time Web Apps and .NET. What are your options?

Specs

  • Author: Nexmo, Phil Leggetter
  • May 2016

Resources

Synopsis

So many applications now offer some form of real-time UX and real-time functionality is becoming increasingly essential as technology trends evolve. Notifications and activity streams in Facebook, Twitter, news and sports apps; real-time location tracking in Uber and most other taxi (logistics) apps; real-time collaboration in Google Docs and Microsoft Office 365 online. What sort of experience would chat apps like Slack, HipChat, WhatsApp, Viber or WeChat offer if messaging weren’t instantaneous? And you can be sure that bots will be powered by real-time technologies.

So, in order to meet user expectations and deliver innovative solutions that align with technology trends, you’re going to need to make use of real-time technologies.

If you build your apps using a .NET stack and you want to add real-time communications functionality to a .NET web app, what considerations should you take into account when choosing a real-time solution? What .NET frameworks or solutions exist? Should you restrict yourself to .NET? If not, how do you integrate with another technology?


Real-time applications using ASP.NET Core, SignalR & Angular

Specs

  • Author: Christos Sakell
  • October 2016

Resources

Synopsis

SignalR has been out for a long time but ASP.NET Core and Angular 2 aren’t. On this post we ‘ll see what takes to bind all those frameworks and libraries together and build a Real time application. This is not an Angular tutorial nor a SignalR one. Because of the fact that the final project associated to this post contains code that we have already seen on previous posts, I will only explain the parts that you actually need to know in order to build a real time application. And this is why I will strongly recomend you to download the Live-Game-Feed app and study the code along with me without typing it. Here’s what we ‘ll see in more detail..


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: 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