Tools, Tips and Techniques

for Developing Real-time Apps

PHIL @LEGGETTERHead of Developer Relations

1 / 89

@leggetter

2 / 89

@leggetter

3 / 89

@leggetter

What we'll cover

1. Why Real-Time?

4 / 89

@leggetter

What we'll cover

1. Why Real-Time?

2. Tools, Tips & Techniques

4 / 89

@leggetter

Why Realtime?

5 / 89

@leggetter

Notifications & Signalling

6 / 89

@leggetter

Activity Streams

7 / 89

@leggetter

Data Visualizations

8 / 89

@leggetter

9 / 89

Chat

@leggetter

10 / 89

@leggetter

Real-Time Location Tracking

11 / 89

@leggetter

Multi-User Collaboration

12 / 89

@leggetter

Multiplayer Games / Art

13 / 89

@leggetter

IoT

14 / 89

@leggetter

Tip #1: Users expect a real-time UX

15 / 89

@leggetter

Tip #1: Users expect a real-time UX

15 / 89

@leggetter

Tip #1: Users expect a real-time UX

Without a real-time UX your app appears

broken

15 / 89

@leggetter

Tools, Tips and Techniques forDeveloping Real-time Apps

16 / 89

@leggetter

The Anatomy of a Real-Time App

17 / 89

@leggetter

Where does real-time datacome from?

18 / 89

@leggetter

Tip #2: You Have Real-Time Data

19 / 89

@leggetter

Tip #2: You Have Real-Time Data

Any event in your web stack...

Incoming DataData ChangesSystem InteractionsUser Interactions

... represents real-time data.

19 / 89

@leggetter

20 / 89

@leggetter

21 / 89

@leggetter

22 / 89

@leggetter

23 / 89

@leggetter

Tools, Tips & Techniques - from left to right

24 / 89

@leggetter

Before we begin...

25 / 89

@leggetter

Before we begin...

Tip #3: When designing & building real-timeapps, always think about how the

decisions you're making - anywhere inyour stack - will impact the client app.

25 / 89

@leggetter

Data Sources

26 / 89

@leggetter

Consuming Data Sources

27 / 89

@leggetter

28 / 89

@leggetter

Code Callbacks

28 / 89

@leggetter

Code Callbacks

WebHooks

28 / 89

@leggetter

Code Callbacks

WebHooks

HTTP Streaming

28 / 89

@leggetter

Code Callbacks

WebHooks

HTTP Streaming

WebSocket

28 / 89

@leggetter

29 / 89

Example: The Twitter Streaming APIWaiting for data...

@leggetter

30 / 89

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

@leggetter

Problem:

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

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

31 / 89

@leggetter

Problem:

You can't always control what the data source sends and when it sendsit. 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

31 / 89

@leggetter

Capture & Replay via Proxies

32 / 89

@leggetter

WebHook Tools

33 / 89

@leggetter

WebHook Tools

Lots of options available

ForwardFinchUltraHooklocaltunnel.mepagekite

33 / 89

@leggetter

WebHook Tools

Lots of options available

ForwardFinchUltraHooklocaltunnel.mepagekitengrok -- use ngrok

33 / 89

@leggetter

34 / 89

0:46

Tip #4: Use ngrok@leggetter

34 / 89

0:46

Tip #4: Use ngrok@leggetter

WebSocket / HTTP Streaming Tools

35 / 89

@leggetter

Proxies

Charles ProxyzaproxyFiddler (Windows/.NET)

36 / 89

@leggetter

GOR

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

github.com/buger/gor

37 / 89

@leggetter

WebSocket / HTTP Streaming ToolsJust write log files

38 / 89

@leggetter

Tip #5:

39 / 89

@leggetter

Logs

Monitor themFilter themBuild tools around themReplay them

40 / 89

@leggetter

41 / 89

Logging Tools

@leggetter

You could...

But I want there to be better options

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

42 / 89

@leggetter

We need better HTTP

Streaming/WebSocket capture & replay

tooling to improve the developer

experience

43 / 89

@leggetter

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

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

44 / 89

@leggetter

Tip #6: The server is your real-time data

work-horse. It should still do the vastmajority of data processing and decision

making. Web, Mobile an IoT clients aregreat, but they're not processing machines.

45 / 89

@leggetter

App Servers

46 / 89

@leggetter

Processing

QueriesTransformationsData formatting

47 / 89

@leggetter

Data Payload

48 / 89

@leggetter

Don't send this When you only need this

Tip #7: Only send the data that is required

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

49 / 89

@leggetter

Send an initial image, then changes

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

50 / 89

@leggetter

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

Send an initial image, then changes

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

50 / 89

@leggetter

{ "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"**}

Send an initial image, then changes

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

50 / 89

@leggetter

{ "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"}

Send an initial image, then changes

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

▼

50 / 89

@leggetter

{ "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"**}

Send an initial image, then changes

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

▼

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

50 / 89

@leggetter

51 / 89

Example: Streaming Tweets to a UINon-Existent-UX

@leggetter

Control the frequency of updates

52 / 89

@leggetter

Control the frequency of updates

100ms is instantaneous to a human

52 / 89

@leggetter

Control the frequency of updates

100ms is instantaneous to a human250ms is average human reaction time

52 / 89

@leggetter

Control the frequency of updates

100ms is instantaneous to a human250ms is average human reaction timeEach update requires some processing

Data parsingUI updates...

52 / 89

@leggetter

Control the frequency of updates

100ms is instantaneous to a human250ms is average human reaction timeEach update requires some processing

Data parsingUI updates...

Consider batching

52 / 89

@leggetter

Real-Time Framework

53 / 89

@leggetter

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

54 / 89

@leggetter

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

55 / 89

@leggetter

Tip #8: You need to know what's going on inyour real-time framework

connectionssubscriptionsmessagespresenceother events/features

56 / 89

@leggetter

LOG ALL THE THINGS

Monitor themFilter themBuild tools around them

57 / 89

@leggetter

58 / 89

Example: Pusher Debug Console@leggetter

58 / 89

Example: Pusher Debug Console@leggetter

Again: Capture & Replay

59 / 89

@leggetter

Did I already mention that we need

better tools for this?

60 / 89

@leggetter

Real-Time Server < - > ClientCommunication

61 / 89

@leggetter

Use the most appropriate transport for your client

62 / 89

@leggetter

BayeuxDDPdNodeEPCPGRIP

MQTTPusher ProtocolSTOMPWAMP (Web App Messaging Protocol)

XMPP (various)Proprietary

What Protocol Should You Choose?

63 / 89

@leggetter

Use the right real-time comms pattern for your app

64 / 89

@leggetter

65 / 89

@leggetter

66 / 89

@leggetter

Tip #9: Choose the right real-time framework for thefunctionality you want to build and the client

devices you're targeting...

67 / 89

@leggetter

FOWA 2013 ForwardJS 2 - 2015

Tip #9: Choose the right real-time framework for thefunctionality you want to build and the client

devices you're targeting...

67 / 89

@leggetter

Soon you won't be able to go to thebathroom† without SSL.† erm, I mean use HTTP/2, ServiceWorker, Fullscreen and many more web features

68 / 89

@leggetter

Soon you won't be able to go to thebathroom† without SSL.† erm, I mean use HTTP/2, ServiceWorker, Fullscreen and many more web features

Tip #10: Use SSL all the time - including indevelopment.

68 / 89

@leggetter

Soon you won't be able to go to thebathroom† without SSL.† erm, I mean use HTTP/2, ServiceWorker, Fullscreen and many more web features

Tip #10: Use SSL all the time - including indevelopment.

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

68 / 89

@leggetter

Client Apps

69 / 89

@leggetter

Client Apps(Breakdown)

70 / 89

@leggetter

Client Apps(Breakdown)

71 / 89

@leggetter

Because we've always considered the

client we're doing everything we can tomake things easy

72 / 89

@leggetter

Because we've always considered the

client we're doing everything we can tomake things easy

Processing - on the serverPayload - focused & minimalImage + ChangesFormatted - further reduce processingUpdate frequency - controlled / batched

72 / 89

@leggetter

Tip #11: Monitor Client Performance - ifyou know how the client is coping, you can

make adjustments.

73 / 89

@leggetter

Latency

Timestamp published messagesCheck time upon receiptConsider:

Timezone differencesSystem clock offsets

If latency gets high, inform the user

74 / 89

@leggetter

Message Backlog

If updating the UI causes a

delay, a queue of messages

can start building up

setTimeoutrequestAnimationFrame

75 / 89

@leggetter

Throttle Updates

Let the server know the client is struggling

RESET

If things get really bad

76 / 89

@leggetter

Using the Real-Time Frameworklibrary withinyour App Logic

77 / 89

@leggetter

We've covered a lot

Data Sources - you can't control the dataData considerations: processing, payload,update frequencyConnectivity - Online/Offline, SSL, transports &protocolsMonitoring client performance

78 / 89

@leggetter

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

79 / 89

@leggetter

80 / 89

How did Ben build this?

@leggetter

Tip #12: Use a service/library abstraction

or stub. Mock out data (messages) &connectivity events.

81 / 89

@leggetter

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;});

82 / 89

@leggetter

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;});

83 / 89

@leggetter

Dev Helpers

leggetter

Hello! Send

Online:

84 / 89

Fake services/stubs@leggetter

Bonus: Abstractions enable change. Youcould swap out the underlying real-time

technology in the future.

85 / 89

@leggetter

App Logic / UIUpdates

As discussed, not covered in

this talk.

But...

86 / 89

@leggetter

Browser Developer Tools are Great!

Performance Monitoring / UI rendering

Advanced Performance Audits With ChromeDevTools - @paul_irishChrome Rendering Performance - @aerotwistMSEdge Dev Tools - PerformanceFirefox Dev Tools - PerformanceHigh Performance Browser Networking -@igrigorik

87 / 89

@leggetter

With these 14 Tools,Tips & Techniques

you can focus on theReal-Time UX

88 / 89

@leggetter

Tools, Tips and Techniquesfor Developing Real-time Apps

Questions?

PHIL @LEGGETTERHead of Developer Relations

89 / 89

@leggetter