@leggetter

@leggetter

@leggetter

@leggetter

@leggetter

Tools, Tips and Techniques
for Developing Real-time Apps

Phil @leggetter
Head of Developer Relations

???

What we'll cover

Why Real-Time? --

background-image: url(https://docs.google.com/drawings/d/1DxIqk4b1LhBadH_O277Vr3wHEBOD8ERZPuO7WNqaFKM/pub?w=1195&h=721)

Tools, Tips & Techniques

???

Firstly, apps don't have to have a UI
Even so, if you are interested in UI considerations then there are lots of great resources on this from browser and mobile vendors.

Why Realtime?

???

Here are some examples of apps...

template: dblue class: em-text, bg-cover, trans-h, bottom background-image: url(./img/itv-news-may-2014.png)

Notifications & Signalling

???

Something has happened
Changed
Alert - do something

class: bg-cover, em-text, trans-h, bottom background-image: url(./img/delighted-app.gif)

Activity Streams

???

a stream of activity
things have - and are - happening
synonymous with social apps
- Twitter
- Facebook
- Google+
- News
- Sports

class: bg-cover, em-text, trans-h, bg-white, bottom background-image: url(./img/senate-election-results.png)

Data Visualizations

Chat

???

The 101 of realtime
An interactive experience
Real-time matters

template: dblue class: trans-h, bg-cover, bottom background-image: url(./img/uber.jpg)

Real-Time Location Tracking

template: lblue class: trans-h, bottom background-image: url(./img/atom-pair.gif)

Multi-User Collaboration

???

Google Apps
Cloud 9
TODO: other

template: lblue class: bg-cover, trans-h, bg-white background-image: url(./img/lunar-landing.png)

Multiplayer Games / Art

IoT

Users expect a real-time UX

--

Without a real-time UX your app appears broken

Tools, Tips and Techniques for Developing Real-time Apps

class: bg-white top black-text background-image: url(https://docs.google.com/drawings/d/1_78n6-fvY8-iacXDtzfRlz0d-m57Ahz6P2DoKkJs_K4/pub?w=1195&h=721)

The Anatomy of a Real-Time App

???

Whilst there's not one true anantomy for a real-time application the majorify of these applications consist of sources of data, maybe from database or 3rd party APIs, one or more applications servers glue all other components together, a real-time framework to deal with your real-time data delivery and functionality, and clients that interact with the real-time framework, and potentially the application server.

Where does real-time data come from?

You Have Real-Time Data

--

Any event in your web stack...

Incoming Data
Data Changes
System Interactions
User Interactions

... represents real-time data.

???

class: bg-white background-image: url(https://docs.google.com/drawings/d/1dL5nNi8l_tjGSKXPCrCfKljMOUmeC8HKU81LrY1x0wU/pub?w=1195&h=721)

???

Other systems that ultimately interact with with your application server. Databases, message queues, 3rd party services and anything that interacts with web endpoints that your application server exposes.

class: bg-white background-image: url(https://docs.google.com/drawings/d/18g94RT1gHtORhiqTZon8j9U_TFtvto0SJJ9SfYejG6g/pub?w=1195&h=721)

???

This is open for debate.

But generally, the application server won't be the source of the real-time data - the real-time events. But it will be the organ within your living breathing real-time system that orchestrates the dataflow between the components.

class: bg-white background-image: url(https://docs.google.com/drawings/d/15fczP5XSDf2uhK43TPgTNYnO2vJDcqFwFwREvgytmUQ/pub?w=1195&h=721)

???

Your real-time framework is all about real-time data.

It handles incoming and outgoing data.
e.g. connections, subscriptions to data, data synchronisation events, over-the-wire method and function calls
Use case specific events e.g. user presence events (online/offline) or events for chat functionality
It will also likely provide access to a number of events specific to the functionality it offers

class: bg-white background-image: url(https://docs.google.com/drawings/d/1rZmX1utBDUNEigmUWrr6WsupuNFoqjSR9jXnEgKjUmQ/pub?w=1195&h=721)

???

Each interaction with the application from the user is a real-time event with associated real-time data. Which of those events is important and should be acted upon depends on your application requirements.

class: bg-white black-text top background-image: url(https://docs.google.com/drawings/d/144h2Lr-x5CAr7v1fqrV0MwHM77Mr5tAHtmpftBJ5j4I/pub?w=1195&h=721)

Tools, Tips & Techniques - from left to right

???

Now that we've truely set the scene, let's make our way through the components in this real-time application and identify the tools, tips & techniques that I've found are really useful as we develop our app.

Before we begin...

--

When designing & building real-time apps, always think about how the decisions you're making - anywhere in your stack - will impact the client app.

???

Data Sources

class: bg-white black-text top background-image: url(https://docs.google.com/drawings/d/1lWV_UBvVoNWgO3u--0L5A6U2YSGSnaLPO_IC6YPF9uU/pub?w=1195&h=721)

Consuming Data Sources

???

When building real-time applications you quite frequently get data from 3rd party components.

APIs/Services
Databases
Queues

There are a lot of potential places where this real-time data can comes from.

class: bg-white fixed-width-list trans-h em-text top background-image: url(img/apps-with-realtime-apis.png)

???

Not only are there lots of options, but they also deliver it in various forms.

--

Code Callbacks

--

WebHooks

--

HTTP Streaming

--

WebSocket

Example: The Twitter Streaming API
Waiting for data...

Example: The Twitter Streaming API
Sometimes there's just too much...

Problem:

You can't always control what the data source sends and when it sends it. Even it you can, it can be tedious to trigger test data.

With REST APIs we can generate fake data. With real-time... ?

--

Solution:

Capture & replay

???

The problem: makes the development phase really difficult.

template: white class: top background-image: url(https://docs.google.com/drawings/d/1l-zpXT0rmra_oAmUJmO7dYiwAebHfUhJ3JTnWrt-fXM/pub?w=1195&h=721)

Capture & Replay via Proxies

???

In production, you can capture this data. But in development you want a simple solution that requires less infrastructure.

WebHook Tools

???

WebHooks are HTTP callbacks from one server to another. They're triggered when one server has data that it wants to send to another, normally via a POST request.

--

Lots of options available

Forward
Finch
UltraHook
localtunnel.me
pagekite --
ngrok -- use ngrok

Use ngrok

-- play_video:

WebSocket / HTTP Streaming Tools

???

HTTP Streaming and WebSocket connections are persistent connections that potentially provide a constant stream of data from the data source.

Proxies

Charles Proxy
zaproxy
Fiddler (Windows/.NET)

GOR

A simple http traffic replication tool written in Go.
No WebSocket support right now

github.com/buger/gor

class: bg-white top black-text background-image: url(https://docs.google.com/drawings/d/1-UKjjtf66kuYihycIQSXFiIIeyYVCYB36-6uppx3KS4/pub?w=1195&h=721)

WebSocket / HTTP Streaming Tools
Just write log files

Logs

Monitor them
Filter them
Build tools around them
Replay them

Logging Tools

???

There are some amazing logging tools out there.

librato
data dog
loggly
logstash

But they do too much. For this, we need something simple.

You could...

log to stdout, use the logfmt format, know your good old grep / sed / awk - @zimbatm

But I want there to be better options

We need better HTTP Streaming/WebSocket capture & replay tooling to improve the developer experience

???

We could do with simpler capture/replay tools

It's all fine and well saying to capture & replay the data. But...

You said, always think about the client! What about the client?

The server is your real-time data work-horse. It should still do the vast majority of data processing and decision making. Web, Mobile an IoT clients are great, but they're not processing machines.

??? Don't just pass all this data directly on to the client.

App Servers

Processing

Queries
Transformations
Data formatting

???

Do whatever you need to do with the data upon receipt.
As mentioned, keep the client in mind as it's them you're going to be delivering to.
What do I mean by that?

Data Payload

???

Here's what a standard tweet JSON looks like. Do I really want to send all this over the wire? It ultimately has to be converted from bytes or a string and parsed into a an object before the client can do anything with it. The larger it is the more work the client has to do.

Only send the data that is required

] .right[ When you only need this

{
  "screen_name": "leggetter",
  "text": "I love to tweet",
  "created_at": "Wed Sep 23 18:10:25 +0000 2015"
}

]

???

Once you've applied the queries or transformations you should only send the data to the client that it needs and is going to use.
Even consider things like formatting dates so they can be directly displayed rather than needing to be parsed and formatted on the client. Or at least send in an easily parsable format.

Send an initial image, then changes

Maintain an image of the current state of data
Only send data that changes

--

{
  "home_team": "Liverpool",
  "home_team_score": 0,
  "away_team": "Arsenal",
  "away_team_score": 0,
  "event_time": "1443117125014"
}

]

{
  "home_team": "Liverpool",
  **"home_team_score": 1,**
  "away_team": "Arsenal",
  "away_team_score": 0,
  **"event_time": "1443117150287"**
}

]

▼

{
  "home_team_score": 1,
  "event_time": "1443117150287"
}

]

Example: Streaming Tweets to a UI
Non-Existent-UX

???

Even if you've made sure you're:

Doing all the heaving lifting on the server
only sending the data that's required You still need to watch how often you're sending

Control the frequency of updates

--

100ms is instantaneous to a human --
250ms is average human reaction time --
Each update requires some processing
- Data parsing
- UI updates
- ... --
Consider batching

Real-Time Framework

class: top background-image: url(https://docs.google.com/drawings/d/1ERZ2boQXQ8PHFF738ZwCupymA7fSKzr8xIjW4SHlJdM/pub?w=1195&h=721)

We know what data we're sending to the Real-Time Framework

???

So, we've covered building up the data payloads that we're going to send to the Real-Time Server...

class: bottom background-image: url(https://docs.google.com/drawings/d/1k_7-4yTvs-cb6slQXvzgBwBL0SaFfE-hSpTjAfnS8Xg/pub?w=1195&h=721)

Can we confirm what's going in?
And see what's going out?

You need to know what's going on in your real-time framework

connections
subscriptions
messages
presence
other events/features

???

As you're developing you really want to know if the code you are writing is having the desired effect. Are connections being established, are subscriptions to data being made, are messages going in to your real-time framework and going out the other side to connected clients?

Is the framework supported functionality working as expected?

## LOG ALL THE THINGS

Monitor them
Filter them
Build tools around them

Example: Pusher Debug Console

--

play_video:

Again: Capture & Replay

Did I already mention that we need better tools for this?

???

TODO: reach out to @zimbatm & @hpoom about real-time logging solutions

class: top background-image:url(https://docs.google.com/drawings/d/1KAb6UWTyOVCWMpf5ZOJHq4eW1nNSBcjnUrDTf0mw7Tw/pub?w=1195&h=721)

Real-Time Server < - > Client Communication

Use the most appropriate transport for your client

???

When thinking about web & mobile WebSocket with HTTP fallback is probably now the defacto standard.
What networks lie between your RT server and the Client?
What's the most efficient connection type for a client?

What Protocol Should You Choose?

Bayeux
DDP
dNode
EPCP
GRIP ] .right[
MQTT
Pusher Protocol
STOMP
WAMP (Web App Messaging Protocol)
XMPP (various)
Proprietary ]

class: trans-h background-image: url(https://docs.google.com/drawings/d/1378sTg1fKEzo4HVBW97JqU0RjJS6u7fsh1hGaCZR0PA/pub?w=960&h=720)

Use the right real-time comms pattern for your app

???

communication patterns on top of transports diagram

background-image: url(https://docs.google.com/drawings/d/1KiPBLoNpAY-4LAdqSE4YsT7_CzusLB5xC9AUYDin7Lg/pub?w=960&h=720) class: bg-white

background-image: url(https://docs.google.com/drawings/d/1mPgTs6fgL6R9-JkCxghNG2x4Jg-0m10oK09KUpO8pHY/pub?w=960&h=720) class: bg-white

Choose the right real-time framework for the functionality you want to build and the client devices you're targeting...

--

FOWA 2013

] .right[

ForwardJS 2 - 2015

]

Soon you won't be able to go to the bathroom^† without SSL.

^† erm, I mean use HTTP/2, ServiceWorker, Fullscreen and many more web features

--

## Use SSL all the time - including in development.

--

You need SSL for networks with proxies and firewalls. In particular, mobile networks.

Client Apps

class: top-left background-image: url(https://docs.google.com/drawings/d/1rOpWrX-4xOoCmXDVuIZI50EKjRPWlIrFtcmYSJfoPuc/pub?w=1195&h=721)

Client Apps (Breakdown)

class: top-left background-image: url(https://docs.google.com/drawings/d/1N6NRRYf_qzDgkpPTmrK5D4F-fttyPwvw0NMs3o8ls3o/pub?w=1195&h=721)

Client Apps (Breakdown)

Because we've always considered the client we're doing everything we can to make things easy

--

Processing - on the server
Payload - focused & minimal
Image + Changes
Formatted - further reduce processing
Update frequency - controlled / batched

Monitor Client Performance - if you know how the client is coping, you can make adjustments.

Latency

Timestamp published messages
Check time upon receipt
Consider:
- Timezone differences
- System clock offsets
If latency gets high, inform the user

background-image: url(https://docs.google.com/drawings/d/1qN0CJUvdhgIc9iZnNiRrFGKggsJ5UxCP57IiCG9vzTI/pub?w=1195&h=721)

Message Backlog

If updating the UI causes a delay, a queue of messages can start building up

setTimeout
requestAnimationFrame

???

http://jsbin.com/sarobe/edit?js,console

Throttle Updates

Let the server know the client is struggling

RESET

If things get really bad

class: top-left background-image: url(https://docs.google.com/drawings/d/1nKhiqmidFMSJuVrWnBYKoLS4UWKsx7HHTzrMbuy-__I/pub?w=1195&h=721)

Using the Real-Time Framework library within your App Logic

???

The point of integration between the real-time tech and your application.

We've covered a lot

Data Sources - you can't control the data
Data considerations: processing, payload, update frequency
Connectivity - Online/Offline, SSL, transports & protocols
Monitoring client performance

Problem: All these things to consider and I just want to build a real-time feature!

How did Ben build this?

???

Now, I'm sure Ben has lots of friends. But do you think he has them round his house for hours on end to help him make sure his demos work?

No!

Use a service/library abstraction or stub. Mock out data (messages) & connectivity events.

Use a service/library abstraction

Angular/Ember/your own Services

var myModule = angular.module('myModule', []);

myModule.factory('pusher', function() {
  var pusher = new Pusher('YOUR_APP_KEY');
  return pusher;
});

Use a service/library abstraction

Angular/Ember/your own Services

var myModule = angular.module('myModule', []);

// myModule.factory('pusher', function() {
//   var pusher = new Pusher('YOUR_APP_KEY');
//   return pusher;
// });

myModule.factory('pusher', function() {
  var pusher = new FakePusher();
  return pusher;
});

Fake services/stubs

Bonus: Abstractions enable change. You could swap out the underlying real-time technology in the future.

class: top-left background-image: url(https://docs.google.com/drawings/d/1S8HlwfMF7iMyoFQhx9YBmVeU3ebyJmjpIPJe9qiSlSk/pub?w=1195&h=721)

App Logic / UI Updates

As discussed, not covered in this talk.

But...

Browser Developer Tools are Great!

Performance Monitoring / UI rendering

Advanced Performance Audits With Chrome DevTools - @paul_irish
Chrome Rendering Performance - @aerotwist
MSEdge Dev Tools - Performance
Firefox Dev Tools - Performance
High Performance Browser Networking - @igrigorik

template: pink class: fixed-width-list top background-image: url(https://docs.google.com/drawings/d/1a-lXfKQ-3wbXMAIxgIEVIVW10jvV4RIQnAe19jnqtk4/pub?w=1195&h=721)

With these 14 Tools, Tips & Techniques you can focus on the
Real-Time UX

]