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.

Why did HTTP/2 impact Websocket's usage? Websockets are still used for real-time server-client communication in many application stacks.

If your use-case for Websockets was "make a bunch of concurrent RPC requests without the browser queuing them" then you can achieve the same concurrency semantics using regular AJAX REST calls, as long as they happen to transit over HTTP/2. For a lot of people, that was all they wanted.

As well, if you add a single SSE channel to that, riding in the same HTTP/2 socket, you now can do everything Websockets can do.

And if you throw a web server like Caddy between your HTTP/2 clients and your application server, now your app server can just be implemented in terms of regular HTTP/1 request-handling, with no need to implement any connection-oriented protocols at all.

Can you clarify what mainstream backend frameworks support any of those?

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.

Are you referring to WebSockets vs HTTP/2 SSE? I think that is just for cache priming and not exposed to applications.

You're thinking of HTTP/2 server push, which is indeed primarily intended for cache priming.

SSE, on the other hand, is for pushing data, over any HTTP version.

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.

And the implementation is really clean too.

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).

Can you do nowadays easily do security for things that are not pure RPC? I remember looking at crossbar.io for the pub-sub features quite a while ago, and securing those was somewhere between a pain and impossible.

crossbar.io now have full featured authentification system, end to end encryption, and permissions isolated in realms. It's work, but yeah, you can secure things.

Securing a website is a lot of work too if you have to do it manually. I just don't do it much anymore, Django takes care of most of the issues for me, and barring some very bad decisions, I have little to actually worry about.

But crossbar doesn't have a django like framework. It's more like flask, express, sinatra...

I've been actually doodling the API of a high level framework on top of crossbar.io for 2 years now. But barring winning the lottery or starting a successful kickstarter, it's unlikely I will find the money to work on it for a year without interruption. It's crazy the amount of work that needs to be done to catch up with frameworks created a decades ago and improved by hundred of dev while field testing it :)

great to hear!

So if a python error object returned contains unpicklable objects, which exception will be returned or will it die?

This is something that absolutely irrelevant to the protocol.

> 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.

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.

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.

I hate to say it but first that sounds highly too stubborn that I wanna say it sounds incompetent. Secondly there's still room to rename and if they want it to go anywhere sooner is bettee than later. Call is Weasel for all anyone cares (yeah I know IceWeasel... But still better than flat out WAMP). The worse part is some people might completely dislike WAMP altogether given some Unix only devs out there and might never see this due to poor naming.

Good technical people are rarely good at communication.

Tobias is a very good, German, technician.

In my experience, really good technical people excel in communication, because that's part of how they became so good.

There's a difference between being talented and being an outstanding technician.

This is true, and I believe sometimes developers should yield certain decisions to somebody else, or be willing to take useful advise (and act upon it after really considering it), you could really go from very good to exceptional if you can get over the hump of "but I already named it a thing", or whatever mental roadblock. As well as you don't have to change your code (reasonable reason not to 'change names'), it can be called 'WAMP' under the hood, but market it as something else, it is the 'WAMP' core if anything, but also clarify that it's nothing to do with Windows, Apache, MySQL or PHP (unless it's related to any of those). At this point if he called it the 'WAM Protocol' it might be a little better.

That didn't stop them from renaming the Company from Tavendo to Crossbar.io, though, it seems. As they are advertising the protocol as "open Web Application Messaging Protocol" they might as well abbreviate it OWAMP. Just sayin'...

I think the owamp is a good idea. I'll try to reach out and show them this thread.

OWAMP would be good because it could benefit from the very similar acronym: OWASP - Open Web Application Security Project.

Heck even WAPPM (Web App Messaging) would work better.

There's also some reasoning on their page: https://wamp-proto.org/faq/index.html#naming

Woah, this page makes it even worst.

"And here is what we recommend for users: [...] Use the hashtag/keyword "wampws" when search on Web platform like Twitter or StackOverflow"

... So why not call it WAMPWS?

This goes for any new project name. Does anyone simply just Google first? If there are a hundred thousand results, choose a new name.

Why do people choose the same name for already known companies/projects to begin with?

We're not talking about names of products. WAMP is a common acronym used in the industry, not a name of a product.

yes I know it well. That is why the quote on the bottom of https://wamp-proto.org/ was amusing to me "WAMP™" etc

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?

It's in the details :

- 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

If nothing else, we need this acronym to mean something - anything - other than Windows/Apache/MySQL/PHP.

Desperately needs a new acronym! Otherwise, this looks pretty neat!

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.

If you just need rest over ajax, wamp is really overkill as you forgo all the tools 10 years of frameworks doing that automatically for you.

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.

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=

Turns out thst’s for every page in that section.

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.

This is amazing. The web badly needed a proper standard for this backed by big industry players.

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.

This looks really cool.

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 :(

Be prepared to do some manual work to wire your site auth with crossbar mechanism. The rest is quite plug and play.

Interesting.

This reminds me of DDP. Meteor had a lot of good things right: https://github.com/meteor/meteor/blob/master/packages/ddp/DD...

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.

One thing I did not understand is whether it supports peer-to-peer operation, or requires (at least one) routing server.

The router is required. The clients don't see each others.

I'm pretty sure it requires a routing server, of which Crossbar is the default (and semi-official) implementation.

Reminds me of SOAP

Yup. As a contractor, I maintained a home grown pre-WAMP (spec) implementation. Think http://autobahn.ws.

I totally didn't get the point. We controlled both the clients and server, so our pre-WAMP was just SOAP style overhead. Meaning useless and confusing.

But the gig paid well and I got some much desired NIO & Netty experience.

what it do what it do

A protocol for RPC and pub/sub over eg. WebSockets