So, you want to build a Real-time API. Where do you start?

Transcript

1. So, you want to build a Real-time API. Where do you start? PHIL @LEGGETTER Head of Evangelism @leggetter
2. What we'll cover 5 Reasons you should offer a Real-Time API Transports Communication Patterns Protocols Security & Scaling Frameworks & Tools Conclusion Real-Time API Quiz (if time)
3. 5 Reasons you should offer a Real-Time API
4. 1. You have Real-Time Data
5. Finding the Real-Time Data Any event in your system = Real-Time Data Changes in data System interactions User interactions
6. youtube.com/watch?v=P31lGHG_lL4
7. 2. Faster access to business value
8. 3. Some Data has a Time Factor
9. WCaaS
10. WCaaS Warp Core as a Service
12. Time Factor Monitoring Market data & betting Communications e.g. phone calls & chat Collaborative experiences
13. 4. Developer Empowerment + Experience
14. leggetter.co.uk/2012/11/06/developers-want- realtime.html Developers Want Real- Time
15. Deliver the new or updated information to them (Push)
16. 5. Users Expect Real-Time Experiences
18. Enable your customers to Build Apps with Real-Time Features with your API
19. Why have a Real-Time API? You have real-time data. Gain value from it! Quick business value Time Factor/Constraints Improve the Developer Experience & Empower them Help consumers building Real-Time features
21. Real-Time API Transports
22. Factors to consider API Consumer? Server or Client Message update frequency Direction of communication Message latency Efficiency
23. WebHooks
24. WebHooks Server only Low update rates Uni-directional Avg. latency High. efficiency (for servers)
26. Server or Client Low update rates Batched bi-directional High latency Low efficiency
27. Server or Client Low update rates Batched bi-directional High latency Low efficiency
29. Server or Client Avg. update rates Batched bi-directional Avg. latency Avg. efficiency
31. Server or Client High update rates Uni-directional Low latency High efficiency
32. Server-Sent Events If you're considering either HTTP Long-Polling or HTTP Streaming then align with the Server-Sent Events standard.
34. Server or Client (normally client) High update rates Bi-directional Low latency High efficiency
35. WebRTC
36. WebRTC Server or Client (normally client to client) High update rates Bi-directional Low latency High efficiency
37. Real-Time Tech Communication Patterns (Not considering WebHooks or WebRTC)
38. Real-Time Tech Communication Patterns Simple messaging Publish-Subscribe RPC/RMI Data Sync
39. Simple messaging No abstractions. Just messages. Fits well with HTTP/REST Many persistent connections
40. PubSub Subscribe & Publish on "channels" Channels. Multiplexed. Single connection Clearly partitions complex data Dedicated endpoint Requires SDK
41. RPC/RMI Call API "methods" Dedicated endpoint + protocol SDK required Hides network activity from developer
42. Data Sync Interact with, and synchronize, data structures Dedicated endpoint + Protocol New paradigm SDK required Hides network activity from developer
43. Real-Time API Frameworks
45. Choose one that meets your requirements How do you do that?
46. Choose one that meets your requirements How do you do that? 1. Choose one that offers the functionality you need
47. Choose one that meets your requirements How do you do that? 1. Choose one that offers the functionality you need 2. Watch my videos :)
50. Real-Time API Tools
51. Real-Time API Tools? Not Many Lots for WebHooks - it's HTTP SwaggerSocket - REST over WS Fanout.io† StreamData.io† SailsJS† † frameworks, but offer a form of tooling
52. So, you want to build a Real-time API. Where do you start? 1. Understand & Identify your valuable Real-Time Data (Events) 2. Define the API Consumer and choose Transports 3. Decide on the best Communication Pattern 4. Can an existing Real-Time Framework help?
53. So, you want to build a Real-time API. Where do you start? 1. Understand & Identify your valuable Real-Time Data (Events) 2. Define the API Consumer and choose Transports 3. Decide on the best Communication Pattern 4. Can an existing Real-Time Framework help? 5. We need better Real-Time API tooling
54. So, you want to build a Real-time API. Where do you start? Questions? leggetter.github.io/realtime-apis PHIL @LEGGETTER Head of Evangelism
55. Appendix
56. Real-Time API Quiz Example Scenarios 1. What transport? 2. What communication pattern? 3. What's the company?
57. Scenario 1 Predefine query within service Push to servers Frequent data updates Potentially large message payloads
58. Scenario 1 Predefine query within service Push to servers Frequent data updates Potentially large message payloads HTTP Streaming
59. Scenario 1 Predefine query within service Push to servers Frequent data updates Potentially large message payloads HTTP Streaming Simple messaging
60. Scenario 1 Predefine query within service Push to servers Frequent data updates Potentially large message payloads HTTP Streaming Simple messaging
61. Scenario 2 Push to server Occasional data updates ("events") Delivery within ~1 of event
62. Scenario 2 Push to server Occasional data updates ("events") Delivery within ~1 of event WebHooks
63. Scenario 2 Push to server Occasional data updates ("events") Delivery within ~1 of event WebHooks Simple messaging
64. Scenario 2 Push to server Occasional data updates ("events") Delivery within ~1 of event WebHooks Simple messaging
65. Scenario 3 Push to browsers, native mobile & anywhere Frequent data updates ("events") Delivery within 250ms Partitioned data
66. Scenario 3 Push to browsers, native mobile & anywhere Frequent data updates ("events") Delivery within 250ms Partitioned data WebSocket + HTTP fallback
67. Scenario 3 Push to browsers, native mobile & anywhere Frequent data updates ("events") Delivery within 250ms Partitioned data WebSocket + HTTP fallback PubSub + events
68. Scenario 3 Push to browsers, native mobile & anywhere Frequent data updates ("events") Delivery within 250ms Partitioned data WebSocket + HTTP fallback PubSub + events
69. Scenario 4 Multi-device comms via central storage Frequent data updates Delivery within 1s
70. Scenario 4 Multi-device comms via central storage Frequent data updates Delivery within 1s WebSocket (+ HTTP Streaming)
71. Scenario 4 Multi-device comms via central storage Frequent data updates Delivery within 1s WebSocket (+ HTTP Streaming) Data Sync
72. Scenario 4 Multi-device comms via central storage Frequent data updates Delivery within 1s WebSocket (+ HTTP Streaming) Data Sync
73. Resources leggetter.github.io/realtime-apis - slides pusher.com - real-time infrastructure as a service Real-Time Technology Guide
74. So, you want to build a Real-time API. Where do you start? Questions? leggetter.github.io/realtime-apis PHIL @LEGGETTER Head of Evangelism