WAMP is a sort of tech that did the same thing as Socket.io when the latter was still really popular, while having nice AMQP-like semantics that gave you full routing, and PubSub and RPC with the same stack. A few years ago, it was promising but didn't seem to get a lot of uptake, and then HTTP/2's rise meant that Websocket fell off the hype train into the dustbin of boring technologies no one blogged about anymore.
This happened right as IDL codegens like Thrift also stopped being talked about, and when people did again, it was all about gRPC, which runs over HTTP/2. This didn't help Websocket either.
Projects like this are especially interesting because they genuinely deliver what they claim to do, but to most people they exist in an alternate universe they've never heard about.
Websockets and http2 don't serve the same purpose. You server code rarely manipulate the http2 stack directly and it's essentially used to serve ressources while websocket is more about pushing notification, giving real time control on knobs and such.
Beside, wamp made to be is used outside the web. You use it to make your server side services talk to each others. Or for iot.
Acronym aside, I think this is fantastic. These patterns (RPC, pubsub) have been around for a while now, and are fairly well understood. Formalizing them into a common, agnostic protocol that everyone can use is a huge win for all parties.
First, it's not just RPC, it's routed RPC. So you basically don't have to know who is providing the procedure and where it is. This also allows transparent fallbacks, hot swap and load balancing of the clients providing the procedure.
Another thing I like is the ease of use. If you used CORBA, XMLRPC or SOAP you know what a pain it is to get it work.
The Python and JS clients just work for me. Transparently: they even get errors back in their native form (ex: python get exception for an error occurring remotely). There is zero mapping to do: you start you client, you register your procedure, and you call it.
The fact is uses websocket is a cool thing too. First, it means you can use it in the browser, and not just nodejs, Python, C#, Java or PHP (but they all have interroperable clients!). But it also means it usually works on your network without the need to setup anything or bother your local sysadmin. And it can benefit from TLS.
It's really sweet.
My only beef is that the Python API is too verbose to my taste, and advance setup for crossbar.io can get complicated if you want to make it super secure (default settings are the equivalent of chmod 777).
> These patterns (RPC, pubsub) have been around for a while now, and are fairly well understood. Formalizing them into a common, agnostic protocol that everyone can use is a huge win for all parties
You could have gotten that same passage out of a needlessly thick CORBA book a quarter century ago. (Unless you did, if this is sarcasm then I salute you).
The problem with adoption of "standard" RPC mechanisms has never been with the underlying transport layer. It's that an interface designed to "look like code" has exactly the property of code, which is that it's fragile in the face of evolution and tends to need to be rewritten every few years when the new generation of hackers gets bored with maintaining the crufty old junk.
You can also use AMQP 1.0, an ISO and OASIS standard protocol, over websockets.
It supports RPC and pub/sub semantics and has client libraries in many languages. It’s implemented by many messaging components as well as Azure Service Bus.
I tried to make a android remote control for a vidoe streaming website with those. I never manage to find a way to make it work after a day. It tool me a few hours with crossbar so i never tried again.
Seconding this one. Database backed AMQP is very robust messaging system. Been using it for a while in production between two specific services, probably going to use it between all microservices in next release (currently using HTTP, haven't had any issues, but like the idea of not having to queue and otherwise manage requests -- to the degree required for HTTP).
I think that one of the main problems with WAMP is that it's just too complex. The RFC is over 150 pages long... For that reason, implementing WAMP is not straight forward.
I think that parts of the WAMP spec are useful to read and I've found it to be a useful guideline for my project but I think that implementing fully WAMP-compatible clients and servers is not realistic at this stage... It's better to just roll your own protocol.
Most implementations of real-time frameworks/libraries use custom protocols and many of them are more widely used than the WAMP protocol.
I agree on the complexity. They traded internal complexity for a simple and easy user experience. WAMP is kinda magic when you use it: languages with very different forms talk to each others reliably with almost no setup, no schema to define, to stuff to prealocate. And it's packed with features too (the wildcards and meta events are insanely powerful).
The price of that is a really heavy spec.
But it's also how the team approach problems. E.G: their Python code really, really looks like Java, with interface everywhere, and wrappers, and factories... If they designed their spec the same way, then it's not surprising.
The german stereotype about engineering is not just a joke.
Boy, this seems like an exceptionally poor choice of project name - in the same exact industry, web development, there is already years of use of "WAMP" to mean "Windows Apache MySQL PHP". WAMP / LAMP / MAMP / etc are ubiquitous.
You know the difference, and I know the difference, but a whole lot of newbie developers who are trying to learn about websockets and while playing around on their Windows dev box could end up pretty confused.
I came here to say the same thing. I have absolutely no idea why such a name would be chosen. The "WAMP" acronym to mean "Windows Apache MySQL PHP" has existed long before this product. Then add to that a quick Google search for WAMP and you will see all of the SEO brings back WAMP server offerings.
This product doesn't even make second page results, and let's be honest most people don't go past the first page of Google results.
I kept telling Tobias (the head of Tavendo, the company behind WAMP) to change the name years ago but he said he already invested too much in it (registration at IANA, tutorial, the fact this is actually WAMP 2, so there was a WAMP 1...).
Basically, yep, it's bad, but this ship has sailed.
This looks like a great library, but a few years too late? Socket.io, SocketCluster.io, gun.js.org (ours), even Meteor, and plenty of other things make it easy to do RPC or get PubSub behavior. Why WAMP over others?
- wamp is a language neutral spec and an open standard registered at iana.
- implementations not only exist in many languages but they are all interroperable transparently despite all feeling very native to their own language. A failing rpc in js will see the error propagated as a python exception on the other side.
- it works in the browser, yes, but it's also very usable as a way to implement micro services or iot clusters. You are not tied to a particular use case or framework.
- not not simple rpc but routed rpc, so the clients don't need to know each others and you can implement fallback, hot reload or load balancing
- security and authentigication are first class citizen
- wamp comes with a lot of goodies like meta events for introspection or wildcards
I inherited a project a while back that used this. It looked brilliant, but the problem was that at least the way the project had been configured, it was not what we needed. In that case, we just needed a simple http-based rest layer over a database, possibly with some queueing off to another system. WAMP appeared to be a very forward-thinking architecture, but I struggled to see how it blended well with that kind of typical use case.
I went to „why wamp” page, scrolled down, there is a section called „also on wamp”, one of the entries is „wamp implementations”. When clicked, it does some redirects and returns with:
NoSuchKeyThe specified key does not exist.implementations/4F6424CF99BA8DC7mv7nfiMNvfiGfUbpMSrbbLzw2pg30iU+BIIxUi+y6ms1+NiTLie+4l1QJFk+6pguD9+FYz8MgH0=
i personally like the stats on the last page of the slide show, and the tailing comment about being benchmarked on a Raspberry Pi. Not that anyone would host a server like this on a PI, but knowing how small of a machine is needed to run something like this is cool.
Of course you could probably do a pretty slick home automation system with this and only a Pi...
:) they have a crazy serious setup for perf testing and published those numbers years ago. It's even better now. I created the slides for my french blog but after receiving a lot of traffic, they contacted me to make an english version that ended up here. It's funny when you think how ugly those slides are, but I did smiled writting the raspi bit.
We use this and have python, js, java and C++ modules talking to each other with it. Doco and examples are so-so but the code is readable and, well, there were implementations for all the languages we needed.
It's weird that an RPC involves http->web socket->wamp plus a bunch of pickling etc but hey, it works and saved us a ton of time.
Doc have improved a lot since the last time i used it in prod, but yeah this is not vuejs doc quality level. I mostly use the demo and example codes to get by.
We have been using WAMP 2 and crossbar in production for a while now. We have js, PHP and python all talking to each other without any issues. We will probably add Go in the next months (prototypes are already working). For authorization and authentication you have to spend some effort to get something working without hardcoded config. Biggest down side is that clustering of the open source router crossbar is not really possible and we haven’t seen any production ready alternatives. Until now this wasn’t really an issue, but it looks like this might be the reason why we will leave WAMP / crossbar this year. Best options to replace this with is probably some solution based on GRPC or NATS.
Also, 3 years ago I would have said it was quite immature. But it matured a lot since then, I had the chance to put it in production. It's not perfect, but it's very cool and is production ready.
And the whole ecosystem is about open standard and open source. Really good vibes.
It doesn't have the Sync primitives but does have some addionnal stuff. I'd say wamp is lower level, requiere more work, is easier to use and more flexible.
[+] [-] niftich|7 years ago|reply
This happened right as IDL codegens like Thrift also stopped being talked about, and when people did again, it was all about gRPC, which runs over HTTP/2. This didn't help Websocket either.
Projects like this are especially interesting because they genuinely deliver what they claim to do, but to most people they exist in an alternate universe they've never heard about.
[+] [-] chrisco255|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
Beside, wamp made to be is used outside the web. You use it to make your server side services talk to each others. Or for iot.
[+] [-] fulafel|7 years ago|reply
[+] [-] SmooL|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
First, it's not just RPC, it's routed RPC. So you basically don't have to know who is providing the procedure and where it is. This also allows transparent fallbacks, hot swap and load balancing of the clients providing the procedure.
Another thing I like is the ease of use. If you used CORBA, XMLRPC or SOAP you know what a pain it is to get it work.
The Python and JS clients just work for me. Transparently: they even get errors back in their native form (ex: python get exception for an error occurring remotely). There is zero mapping to do: you start you client, you register your procedure, and you call it.
The fact is uses websocket is a cool thing too. First, it means you can use it in the browser, and not just nodejs, Python, C#, Java or PHP (but they all have interroperable clients!). But it also means it usually works on your network without the need to setup anything or bother your local sysadmin. And it can benefit from TLS.
It's really sweet.
My only beef is that the Python API is too verbose to my taste, and advance setup for crossbar.io can get complicated if you want to make it super secure (default settings are the equivalent of chmod 777).
[+] [-] ajross|7 years ago|reply
You could have gotten that same passage out of a needlessly thick CORBA book a quarter century ago. (Unless you did, if this is sarcasm then I salute you).
The problem with adoption of "standard" RPC mechanisms has never been with the underlying transport layer. It's that an interface designed to "look like code" has exactly the property of code, which is that it's fragile in the face of evolution and tends to need to be rewritten every few years when the new generation of hackers gets bored with maintaining the crufty old junk.
[+] [-] lulf|7 years ago|reply
It supports RPC and pub/sub semantics and has client libraries in many languages. It’s implemented by many messaging components as well as Azure Service Bus.
[+] [-] sametmax|7 years ago|reply
[+] [-] jexah|7 years ago|reply
[+] [-] grosjona|7 years ago|reply
I think that parts of the WAMP spec are useful to read and I've found it to be a useful guideline for my project but I think that implementing fully WAMP-compatible clients and servers is not realistic at this stage... It's better to just roll your own protocol.
Most implementations of real-time frameworks/libraries use custom protocols and many of them are more widely used than the WAMP protocol.
[+] [-] sametmax|7 years ago|reply
The price of that is a really heavy spec.
But it's also how the team approach problems. E.G: their Python code really, really looks like Java, with interface everywhere, and wrappers, and factories... If they designed their spec the same way, then it's not surprising.
The german stereotype about engineering is not just a joke.
[+] [-] sethhochberg|7 years ago|reply
https://en.wikipedia.org/wiki/WampServer
You know the difference, and I know the difference, but a whole lot of newbie developers who are trying to learn about websockets and while playing around on their Windows dev box could end up pretty confused.
[+] [-] bigtunacan|7 years ago|reply
This product doesn't even make second page results, and let's be honest most people don't go past the first page of Google results.
[+] [-] sametmax|7 years ago|reply
Basically, yep, it's bad, but this ship has sailed.
[+] [-] porsager|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] overcast|7 years ago|reply
[+] [-] eurticket|7 years ago|reply
[+] [-] liveoneggs|7 years ago|reply
[+] [-] bigpoppa|7 years ago|reply
[deleted]
[+] [-] marknadal|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
- wamp is a language neutral spec and an open standard registered at iana.
- implementations not only exist in many languages but they are all interroperable transparently despite all feeling very native to their own language. A failing rpc in js will see the error propagated as a python exception on the other side.
- it works in the browser, yes, but it's also very usable as a way to implement micro services or iot clusters. You are not tied to a particular use case or framework.
- not not simple rpc but routed rpc, so the clients don't need to know each others and you can implement fallback, hot reload or load balancing
- security and authentigication are first class citizen
- wamp comes with a lot of goodies like meta events for introspection or wildcards
[+] [-] jMyles|7 years ago|reply
[+] [-] lprd|7 years ago|reply
[+] [-] poulsbohemian|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
Beside, crossbar really need a task queue architecture. It's basically half of it, so i guess we could plug in celery in the mix and some glue code.
[+] [-] rad_gruchalski|7 years ago|reply
NoSuchKeyThe specified key does not exist.implementations/4F6424CF99BA8DC7mv7nfiMNvfiGfUbpMSrbbLzw2pg30iU+BIIxUi+y6ms1+NiTLie+4l1QJFk+6pguD9+FYz8MgH0=
Turns out thst’s for every page in that section.
[+] [-] dlhavema|7 years ago|reply
Of course you could probably do a pretty slick home automation system with this and only a Pi...
[+] [-] sametmax|7 years ago|reply
[+] [-] gumby|7 years ago|reply
It's weird that an RPC involves http->web socket->wamp plus a bunch of pickling etc but hey, it works and saved us a ton of time.
[+] [-] sametmax|7 years ago|reply
[+] [-] rvdmei|7 years ago|reply
[+] [-] jgalvez|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
And the whole ecosystem is about open standard and open source. Really good vibes.
[+] [-] cstrat|7 years ago|reply
I currently use Meteor for webapp development, but when I really look into it the main parts of meteor I use are pub/sub & method calls.
The rest is just react, react router, and the meteor build tools which can be swapped out.
This looks like a promising light weight alternative... plus meteor doesn't run on raspberry pis :(
[+] [-] sametmax|7 years ago|reply
[+] [-] dfischer|7 years ago|reply
This reminds me of DDP. Meteor had a lot of good things right: https://github.com/meteor/meteor/blob/master/packages/ddp/DD...
[+] [-] sametmax|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] nine_k|7 years ago|reply
[+] [-] sametmax|7 years ago|reply
[+] [-] acemarke|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] bullen|7 years ago|reply
Try http://fuse.rupy.se instead.