2. Problem #1
Traditionally, web applications have been built to mirror static print.
➔ Pages and HTML always have a snapshotted state
➔ Users must request a new snapshot to retrieve more up to date information
➔ As soon as the request is met, the information returned can be outdated.
The problem here is that in a digital age, information is no longer static; it’s
dynamic and fluid and can be updated on the fly.
The future of the web is real-time. Just looking at the applications we use
personally as conclusive evidence. It’s no longer acceptable for our apps to
passively wait for users to refresh. Instead, we must build our apps to keep
themselves up to date.
3. Remote Procedure Calls vs. Publisher/Subscriber
Remote Procedure Calls
Call based, “request/reply” routing
“As Needed” Connection
1-1 Communication
Good for sync/async
Publisher/Subscriber
Event based, “fire and forget” routing
“Always Listening” Connection
1-Many Communication
“Soft” real-time
Publisher Subscriber
Broker
Caller Callee
4. Problem #2
There are few cases in which you would not need to both send and request
data as well as receive automatic updates.
This leads to using 2 technologies for your app’s messaging and has clear
disadvantages:
● You need 2 tech stacks, possibly including 2 servers (or 2 tech stacks on a
single server) always synced.
● The app needs separate connections for the 2 messaging patterns,
requiring more server resources. Both require their own auth, increasing
implementation complexity.
● Front-end concerns are similar: establishing and handling 2 connections
and dealing w/ 2 separate APIs.
6. What is WAMP?
You mean Windows, Apache, MySQL, and PHP? NO!!!
WAMP is an open standard WebSocket sub-protocol that provides 2
application messaging patterns in 1 unified protocol: RPC + PubSub
➔ Unified Application Routing supports event based routing & call based
routing
Using WAMP you can build distributed systems out of application components
that are loosely coupled and communicate in “soft” real-time.
You have a single library, connection, and API. It will handle all of your app’s
messaging between the browser front-end and the application back-end.
7. RPC + PubSub = WAMP
Remote Procedure Calls PubSub
Publisher Subscriber
Broker
Caller Callee
Dealer
To achieve the same decoupling as PubSub, WAMP introduces the Dealer as an
intermediary.
Like the PubSub broker, the dealer routes calls from the Caller to the Callee and back.
Router Broker Broker
10. WAMP - Under the Covers
WAMP runs on top of WebSockets, a Web protocol that
provides bidirectional, real-time communication.
➔ Builds up WebSockets by providing high level
messaging patterns: RPC + PubSub
➔ Uses JSON as its messaging format
➔ Can also use MessagePack or any bidirectional, reliable
message transport
11. Example
Bug Tracker
Technologies
● Router is crossbar.io
● Backend Clients: Node server
● Front End Clients: static site using Polymer, LoDash, and Promise Polyfill
Scope
● Read a JSON list of bugs
● Create Bugs
● Move Bugs to Open, Working, or Done states
● Broadcast creates/updates/deletes
12. Notables Using WAMP
Kadecot - A Home Automation product developed by Sony
Computer Science Lab
Record-Evolution - An advanced Data-Warehouse and
Business Intelligence solution
Kitware - A 3D scientific visualization solution
13. Summary
WAMP is awesome…
...because it allows you to decouple your application
...because it is language agnostic
...because it allows for RPC + PubSub messaging under one protocol
...because it allows for RPC + PubSub messaging under one tech stack