Real-time is becoming the life blood of applications. Facebook, Twitter, Uber, Google Docs and many more apps have increased user expectation to demand real-time features. Features such as notifications, activity streams, real-time data visualisations, chat or collaborative experiences instantly keep users up to date and enable them to work much more effectively. So, how do you build these sorts of features with .NET?
In this session, Phil will cover the benefits of moving away from polling to push, the options you have with .NET web application to do this and when adding real-time features to your apps, and the pros and cons of each to help choose which is the best solution for you.
4. What we'll cover
1. Why Real-Time?
2. Common Real-Time Use Cases
3. What are your options?
How do you choose?
.NET examples
Pros & Cons
4. The Future of Real-Time
4 / 121
@leggetter
12. These aren't new Needs or Demands
But...
The Internet
9 / 121
@leggetter
13. Internet
“a global computer network providing a variety
of information and communication facilities,
consisting of interconnected networks using
standardized communication protocols.
10 / 121
@leggetter
25. Technology Advancements
Memory & CPU speed and cost
The Cloud
Browser standardisation & enhancements
Any client can use the standards
21 / 121
@leggetter
29. Internet Usage (per day)
200 billion emails
7 million blog posts written†
500 million tweets
30 billion WhatsApp messages
24 / 121
@leggetter
30. Internet Usage (per day)
200 billion emails
7 million blog posts written†
500 million tweets
30 billion WhatsApp messages
55 million Facebook status updates
5 billion Google+ +1's
60 million Instagram photos posted
2 billion minutes spent on Skype
33 million hours of Netflix watched
750 million hours of YouTube watched
24 / 121
@leggetter
48. Polling Calculations
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, with a 10 second polling interval
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
38 / 121
@leggetter
49. Polling Calculations
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, with a 10 second polling interval
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. Poll requests per user/minute = (60 / 10) = 6
38 / 121
@leggetter
50. Polling Calculations
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, with a 10 second polling interval
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. Poll requests per user/minute = (60 / 10) = 6
5. Poll requests per user/hour = (6 * 60) = 360
38 / 121
@leggetter
51. Polling Calculations
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, with a 10 second polling interval
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. Poll requests per user/minute = (60 / 10) = 6
5. Poll requests per user/hour = (6 * 60) = 360
6. Poll requests site wide per hour = (360 * 10,000) = 3,600,000
38 / 121
@leggetter
52. Polling Calculations
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, with a 10 second polling interval
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. Poll requests per user/minute = (60 / 10) = 6
5. Poll requests per user/hour = (6 * 60) = 360
6. Poll requests site wide per hour = (360 * 10,000) = 3,600,000
With polling the site would need to handle 3.65 Million requests per hour
Or 50k HTTP requests + maintain 10k persistent connections?
38 / 121
@leggetter
54. 2. Use an existing solution
Don't reinvent the wheel
Unless you've a unique use case
40 / 121
@leggetter
55. Why use an existing solution?
Connection fallback/upgrade hacks still required
WebSocket: 91% of connections
HTTP fallback: 9% of connections
41 / 121
@leggetter
56. Why use an existing solution?
Connection fallback/upgrade hacks still required
WebSocket: 91% of connections
HTTP fallback: 9% of connections
Support/Community
41 / 121
@leggetter
57. Why use an existing solution?
Connection fallback/upgrade hacks still required
WebSocket: 91% of connections
HTTP fallback: 9% of connections
Support/Community
Maintenance
41 / 121
@leggetter
58. Why use an existing solution?
Connection fallback/upgrade hacks still required
WebSocket: 91% of connections
HTTP fallback: 9% of connections
Support/Community
Maintenance
Future features
41 / 121
@leggetter
59. Why use an existing solution?
Connection fallback/upgrade hacks still required
WebSocket: 91% of connections
HTTP fallback: 9% of connections
Support/Community
Maintenance
Future features
Scaling
41 / 121
@leggetter
75. Simple Messaging
// client
var ws = new WebSocket('wss://localhost/');
ws.onmessage = function(evt) {
var data = JSON.parse(evt.data);
50 / 121
@leggetter
76. Simple Messaging
// client
var ws = new WebSocket('wss://localhost/');
ws.onmessage = function(evt) {
var data = JSON.parse(evt.data);
// ^5
performHighFive();
};
50 / 121
@leggetter
77. Simple Messaging
// client
var ws = new WebSocket('wss://localhost/');
ws.onmessage = function(evt) {
var data = JSON.parse(evt.data);
// ^5
performHighFive();
};
// server
server.on('connection', function(socket){
50 / 121
@leggetter
78. Simple Messaging
// client
var ws = new WebSocket('wss://localhost/');
ws.onmessage = function(evt) {
var data = JSON.parse(evt.data);
// ^5
performHighFive();
};
// server
server.on('connection', function(socket){
socket.send(JSON.stringify({action: 'high-5'}));
});
50 / 121
@leggetter
79. Simple Messaging
using Nexmo.Api;
// SMS
var results = SMS.Send(new SMS.SMSRequest
{
from = "15555551212",
to = "17775551212",
text = "this is a test"
});
// Voice
var result = Voice.TextToSpeech(new Voice.TextToSpeechCallCommand
{
to = "17775551212",
from = "15555551212",
text = "Hello from Nexmo"
});
51 / 121
@leggetter
104. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
63 / 121
@leggetter
105. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
ref.on('child_added', function(childSnapshot, prevChildKey) {
// code to handle new child.
});
63 / 121
@leggetter
106. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
ref.on('child_added', function(childSnapshot, prevChildKey) {
// code to handle new child.
});
ref.on('child_changed', function(childSnapshot, prevChildKey) {
// code to handle child data changes.
});
63 / 121
@leggetter
107. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
ref.on('child_added', function(childSnapshot, prevChildKey) {
// code to handle new child.
});
ref.on('child_changed', function(childSnapshot, prevChildKey) {
// code to handle child data changes.
});
ref.on('child_removed', function(oldChildSnapshot) {
// code to handle child removal.
});
63 / 121
@leggetter
108. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
ref.on('child_added', function(childSnapshot, prevChildKey) {
// code to handle new child.
});
ref.on('child_changed', function(childSnapshot, prevChildKey) {
// code to handle child data changes.
});
ref.on('child_removed', function(oldChildSnapshot) {
// code to handle child removal.
});
ref.push({ 'editor_id': 'leggetter', 'text': 'Nexmo Rocks!' });
63 / 121
@leggetter
109. Data Sync
// client
var ref = new Firebase("https://app.firebaseio.com/doc1/lines");
ref.on('child_added', function(childSnapshot, prevChildKey) {
// code to handle new child.
});
ref.on('child_changed', function(childSnapshot, prevChildKey) {
// code to handle child data changes.
});
ref.on('child_removed', function(oldChildSnapshot) {
// code to handle child removal.
});
ref.push({ 'editor_id': 'leggetter', 'text': 'Nexmo Rocks!' });
Framework handles updates to other clients
63 / 121
@leggetter
138. Pros
.NET
Maps well to PubSub
Loosely coupled
Could use another runtime
Cons
How does it fit with RMI/SignalR?
Multiple components
Self-scaling
Queue routing questions
In: HTTP. Out: WebSocket
Self-Hosted: .NET + Message Queue - Pro &
Cons
84 / 121
@leggetter
146. Pros
Simple & powerful
Instantly scalable
Managed & dedicated
Direct integration. No overhead.
Cons
3rd party reliance
Difficult to influence functionality
Hosted - Pros & Cons
90 / 121
@leggetter
147. Why use a hosted service?
Scenario
1. Site average of 10,000 Users
91 / 121
@leggetter
148. Why use a hosted service?
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, no polling
91 / 121
@leggetter
149. Why use a hosted service?
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, no polling
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
91 / 121
@leggetter
150. Why use a hosted service?
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, no polling
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. That's it! Total: 50,000
91 / 121
@leggetter
151. Why use a hosted service?
Scenario
1. Site average of 10,000 Users
2. Over 1 Hour, no polling
3. Requests from pages load + HTML, CSS, JS, Images for 10k users = 50,000
4. That's it! Total: 50,000
Your servers handle 50k requests per hour instead of 3.6M
You offload the polling or persistent connections to the service
91 / 121
@leggetter
154. How do you choose?
7 Realtime Framework Considerations
1. Should you keep on polling?
2. Use an Existing Solution
3. Use a language you're comfortable with
4. Do you need native mobile support?
5. Simple Messaging, PubSub/Evented, RMI or DataSync
6. Architectural considerations
7. Hosted v Self-Hosted (Build vs. Buy)
94 / 121
@leggetter
165. A thing can be anything
Sensors
Appliances
Vehicles
Smart Phones
Devices (Arduino, Electric Imp, Raspberry Pi etc.)
104 / 121
@leggetter
166. A thing can be anything
Sensors
Appliances
Vehicles
Smart Phones
Devices (Arduino, Electric Imp, Raspberry Pi etc.)
Servers
Browsers
Apps: Native, Web, running anywhere
104 / 121
@leggetter
167. The Majority of code we'll write will still be
for "Apps"
Configuring
Monitoring
Interacting
App Logic
105 / 121
@leggetter
168. Real-Time Use Case Evolution
Notifications & Signalling
Activity Streams
Data Viz & Polls
Chat
Collaboration
Multiplayer Games
106 / 121
@leggetter