The Web Application Messaging Protocol; from a Pythonic perspective.
Most Python Engineers I meet and talk to now are free to live the dream of Python 3 and asyncio. Employers are actually giving us the freedom and time to do the switch, whilst new projects are always done in Python 3.
And there are far more exciting choices for engineers now than just Flask and Django apps, for example, Falcon, Sanic and nameko: the future is bright! I believe that part of this future is the relatively unknown Web Application Messaging Protocol, or “WAMP” — which is definitely not to be confused with the Microsoft web development platform.
Your immediate problem with this technology might actually be how to pronounce the acronym — I have always said WAMP as I would “swamp”… and I do hope that I am correct :)
WAMP first got my attention when I was working on the backend of the onefinestay website, which at the time was a Django app with 60+ micro-services working over AMQP in the backend. There were living and breathing web pages forced to let HTTP requests hang on the AMQP backend, when there was a single protocol that could have met all requirements: WAMP.
OK, now let’s get into some details as to exactly what WAMP looks and feels like and then as to why — just maybe — you should be interested in WAMP.
What is WAMP?
This is the Web Application Messaging Protocol and it is a straightforward way to send messages between distributed applications, regardless of whether they are a “web app” or not. WAMP is a WebSockets sub-protocol. It is work in progress as an Internet Draft and you can see the latest draft here while the project itself here.
More precisely, it is persistent and bi-directional TCP communication between unlimited applications, distributed and load-balanced over a broker/router, but typically WebSocket communication over Crossbar.io: think about RabbitMQ and AMQP if that helps.
To use WAMP, your applications need a Router with a Realm (a routing namespace) to connect to and then they can exchange messages using WAMP’s two communication patterns: routed Remote Procedure Calls and Publish and Subscribe. Applications register procedures they expose with the Router where they are identified by URIs. Likewise, applications can notify the Router of an interest in a Topic, i.e. subscribing to a Topic.
Both cases decouple your apps: the Caller does not know where or who the Callee is, nor does any Publisher know of any Subscribers.
The Protocol describes how your application components first contact the router (Hello) then register procedures (Register), subscribe to Topics (Subscribe), send Messages (Call and Publish), receive Messages (Invocation and Event) and then detach from the Router (GoodBye). This is done with WAMP Messages.
Messages are (usually, but can be MessagePack) a JSON serialised list of data packed into WebSocket Frame payloads. WAMP components in your stack will need to construct the data structure for a given Message type, JSON serialise it, pack it in WebSocket Frame(s) and send it down the wire. On receipt of data, payloads need to be read, extracted, deserialised and the Message acted upon according to the protocol. Luckily, your WAMP framework or client will abstract the complexity of WAMP Messages away from you, letting you concentrate on building apps.
Your applications (or WAMP “Peers”) will be implementing WAMP Roles. Any WAMP application is free to be a Publisher, Subscriber, Caller or Callee. This is whether your app is embedded in a web page, running as a micro-service supporting a wider infrastructure, or something totally different.
You may want to dive in now and play with this technology? If so, there are options for many languages here. Two standout Python implementations are Autobahn and wampy, and for the front-end you have the Javascript wampy.js.
Autobahn has some comprehensive examples, and wampy has two simple use cases on its README.
Why would you want to WAMP?
- You have a micro-service or event-driven backend architecture and it needs to work seamlessly with your web and mobile apps
- You require a message bus, possibly to help scale your apps
- You require, or are considering, RPC and/or PubSub for one of your solutions
- You have IoT projects that connect devices but need more than MQTT offers
- You are involved with, or building, Chat systems
- You provide real-time updates to browsers
- You build collaborative apps
- You build mobile applications
- Or… you simply just build and enjoy building… Web Apps!
There are some advantages you get out of the box with WAMP.
- WAMP decouples every application you write
- WAMP is language and framework agnostic
- WebSockets are not the only transport this is bound to
- WAMP supports many auth patterns
- You get load balancing for free
And having worked in an environment of literally hundreds of HTTP based micro-services, I reached the end of my tether figuring out where the 502s and 504s were coming from! I much prefer using faster RPC patterns than slow HTTP calls anyway, but neck deep in upstream HTTP calls can quickly become harder to manage and debug than the same applications but over a Broker.
Is It Production Ready?
The protocol itself is exceptionally well thought through so it’s the implementations you are interested in, notably the router.
Crossbar.io is the most popular and feature-rich WAMP implementation and this is a secure and reliable option for your Router. It is open-source and is developed, maintained and supported by the Crossbar.io organisation, and the Python Community.
To make this “production ready” your DevOps/Platform team will demand and ask about certain things: high availability, clustering, monitoring, alerting, scaling, deployment automation, log message aggregation, and… possibly Unicorns, in order to make them adopt something that looks a little out of the ordinary and risky.
Crossbar.io is a few years old now at least, but not as mature as well-established technologies that DevOps/Platform teams typically work with. Crossbar has a DevOps Community and a Roadmap which are good starting points for your conversation. If you are happy to pay, then go straight to commercial support.
What Next?
Get the user base up, get the interest up, get people talking about WAMP online and at conferences… and let’s see if this really is a hit or not?!
Thanks for reading, and I hope I have sparked some interest in WAMP.
Disclaimer: I am the author of wampy, and the cow is not mine.
