Ape: Ajax Push Engine

Let me say a few words about Ape, an Ajax push server I came across this week:


Even though the authors say it’s a stable 1.0 release and “insanely great”, there are some issues you should be aware of. I write this in the hope that it helps others to evaluate the server and to give feedback to the developers. The general idea of combining fast C code with JavaScript is very good. It’s still a young Open Source project and has a lot of potential.

Incomplete documentation

It turned out to be a little bit challenging to develop code for Ape because of the quality of the documentation. There is an API documentation (which is not good for new users) and there is a Wiki with some links leading to missing pages. Most of the examples deal with how to implement a chat server. In fact Ape was previously named ACE (Ajax Chat Engine). It’s sometimes hard to understand how to use it for a general purpose application and what the limits are.

Maximum length of channel names

One of these limitations is the maximum length of 40 characters for channel names. In my library I use channel names like ‘foo.bar.baz’ that can be easily published with OpenAjax on the JavaScript side. Some of these events never arrived nor did the subscribe function throw an exception.

Nickname required to connect to server

At first it seemed like the server requires a nickname to connect, which makes sense for chat applications only. Not every Web site out there should ask the user to enter his nickname, right? After investigating the issue (I didn’t find a hint in the documentation), I found out that an example server-side script in /var/ape/examples was causing this behavior. You can comment out this line in main.ape.js to “fix” it:


Error when sending messages to empty channels

If you happen to send a message to a channel that is currently not subscribed (Ape calls it “joined”, like in a chat software), you’ll get an error. This behavior is strange, if you are used to other message servers that just accept the message, even if nobody will ever get it. If you know this can happen, it’s not so much of an issue anymore.

Complicated domain name setup

Ape uses sub domains in the form of [Number].ape. to communicate with the JavaScript client. Each connect increases the number (which is stored in a cookie) by one. They call the numbers “frequencies”. According to the documentation, this concept should provide sessions within a session, if you open multiple tabs in the same browser. I’ve never seen something like that before. I disabled the feature by modifying their code and tracking the different tabs on the server side. My code will be published later, so you can copy this, if you like. Another problem with the changing domain names is that you have a hard time to set this up locally in /etc/hosts – there is no support for wildcards.

Config directly inside the JavaScript library

I found it really strange to configure the Ape server URL directly in Build/uncompressed/apeClientJS.js. If you ever update this file, your config will be overwritten. Why not provide the config as a parameter to the load() or constructor function? Again, I modified the code.

Based on MooTools

There are two versions of the client library, one for MooTools and one for other JavaScript frameworks, which includes MooTools. I did not find out yet, why you need MooTools to write an Ajax push library for general usage. I also did not investigate how many files are loaded additionally when the Ape library is included. My feeling tells me, that this whole thing can be improved and that the library should be compressed and put in one single file.

No standard protocols

Even though it probably is possible to connect Ape to a general usage message server (like ActiveMQ or RabbitMQ) with some additional work, it does not offer a standard STOMP or AMQP interface by default. The Web site states that the Ape protocol is faster than everything else. So far, I was not able to confirm or reject that claim ;)

JavaScript on the server side

It is convenient to be able to use JavaScript on the server side. Just let me note that this can lead to previously unexpected errors. JavaScript is a loosely typed language and if you happen to return a number instead of a string as nickname to the server, you will see this exception:

/var/ape/examples/nickname.js:6:TypeError: params.name.toLowerCase is not a function


  1. Christopher

    A lot of great insights.

    Have you considered forking http://github.com/APE-Project so you can share your changes?

  2. Michael (Post author)

    Yeah, I should. Thanks for the hint, even though I don’t want to push half-done code there. I wrote a PHP/JS AJAX lib for AJAX push and JSON-RPC, that works with Ape and Orbited. That one might get published this week-end.

  3. Martin

    Hi, thanks for the article. I recently tried out the APE, my dev team hopes to use Comet for our PHP/jQUery-based web browser game (no Flash, just HTML/JS.

    The same as you, I was disappointed to see the a bit out of date documentation, weird mixing of bloated JS libraries and crazy subdomain config :(

    We have looked for other options for some simple but powerful and free for commercial use Comet server which has PHP support, but it seems the only alternative to APE is this:
    Seems just a nice and basic Comet implementation with no bloat.

    We discarded Lightstreamer, WebSync, Liberator, StreamHub, WebSync, CometD because they had some serious limits in free versions or too Java/Python-oriented and not friendly with PHP.

    If you have some advice or some code patches which will make APE to behave more “natural” and easier to use, I would be grateful.

    What would you suggest – keep with APE or go for NGINX with NGiNX_HTTP_Push_Module?

  4. Michael (Post author)

    Actually, I did use Ape for http://www.chaoticpattern.net/#wiki/index – but I had to turn it off again, because of strange connection problems (still under investigation). In case you understand German, the docs for my lib are here: http://www.chaoticpattern.net/#wiki/Liquid_Ajax (Download link will follow soon).

    Sooner or later, I will add more connection handlers to Liquid_Ajax. Ape and Orbited are the only ones currently supported and both have their downsides/bugs. Guess there is no way around Java, if you want a stable AJAX push server. This is not a problem, as the connection from PHP to the server uses the STOMP protocol, which is platform independent. There already is a STOMP adapter for the Liquid_Ajax_Controller. Just the JS counterpart and a stable AJAX push server are still missing…

  5. Sheldon

    I came across a similar project that I’ll likely be using – hookbox.org. Doesn’t seem to have the documentation issues that APE apparently has.

Leave a Reply