At Superfeedr, we’ve always been great fans of node.js. We believe the ability to use the same language on both servers and clients will breed a whole new generation of web developers that can do amazing work on both ends. Last year already, we released node.js code a couple hours ahead of NodeKO, and this year, we’re doing it again.
A node KO treat
In the context of the msgboy (request your invite now!), we had to setup a new XMPP server. After fighting with ejabberd, we installed Prosody, but we also quickly concluded that we would need a lot of customization, as well as the ability to tweak our server(s) to fit our exact needs.
Since astro had been doing an amazing work with his node-xmpp library to build Client, Components and even Server to Server modules, the logical next step was to try to build a Client to Server module so that we could have a full blown server. That’s what we worked on the past couple days, and it’s now on Github!
Beware though… as it’s extremely early and some key features are not yet supported. Our biggest challenge is trying to fix a weird TLS bug. Please help if you can!
Let’s get dirty
If you’re brave enough and want to get started, install our branch of node-xmpp from source. You should then be able to run a server by typing
$ node examples/c2s.js
Now, take your favorite XMPP client (we used Psi, but you need to make sure it will accept to transmit PLAIN text passwords over an unencrypted connection) and connect to the server as email@example.com. Use
password for the password.
Now, that was
relatively easy, and quite useless so far, as you could do that with any XMPP server out there. The real interest of this one is that we wanted to give full control back to the developer to customize their server as much as they needed. Take a look at the
examples/c2s.js file for the code that runs this specific server:
- Auth is simple: the c2s module will just callback with a username and a password. Your code should then decide whether you want to authorize or not connection, based on your database, or any other piece of application that you want.
- You can define modules supported by your server from the most popular XEPs, using
node-xmpp’s mixins. The modules should be at the heart of any implementations, as we want to keep the c2s code itself very bare.
- There are currently 4 events that you can listen to on the C2S module itself :
connect, disconnect, authenticate, stanza, which are relatively self explanatory. The
connectevent should be used to register mixins to user connections. The
stanzaevent should probably be left empty (unlike in the example), as all meaningful stanzas should probably be treated in mixins.
Also, you get all the JS magic that lets you rewrite any code without much hassle. One of the key aspects of most XMPP servers is their -in-ability to be deployed in clusters to handle more users. For those who want to dive in that direction, Redis’s PubSub provides an elegant solution. Combining this with some sharding on the jids should probably go a long way! You can see in the basic example below that we rewrote the routing mechanism to use Redis and run multiple instances of the same server in a cluster.