My Questions to APE – answered
I’m planning to use APE (www.ape-project.org) for my next big project. It provides “Real-Time-Push” functionality based on Java Script, making real-time web applications possible.
After playing with it for some time now, getting the demos to run and trying out some stuff on my own, I wanted to share some of the things I learned.
Before I started playing with APE, I put down some basic questions occuring in my head. I would have liked to get them clarified directly to get a better overview of what I’m dealing with. Unfortunately, the documentation is a little bit thin on giving you a “basic big picture” before it goes into API calls and Event details.
So, a couple of days ago, I just put down the basic questions I had at the beginning – and hopefully, as I got a better understanding now, I found answers – and maybe you can use my notes to get the big picture easier than I did…
My initial Questions and their answers after playing with it
Ape works with pipes – what are pipes?
A kind of virtual “handles” in the framework to communicate with the server or another users. If you joined a channel, the server will tell you which users are connected to it – along with their “pipe”. And you can send a message to that pipe – the server will forward it to the user.
How does the server know if a user is allowed to join a channel?
If the server does not have any additional intelligence, it does not care. Its up to the server, to decide what to do.
If I’m implementing a chat with privat chatrooms, how can I prevent a “bad” user from joining a private channel if he guesses the name or finds out about the user?
A client sends a message to another user “on a pipe” to the server, the server will pass on the message – so there is no public/private channel, but a direct user pipe that cannot be intercepted
How do channels get their name at all?
You need to know the name to connect to it – or you just create one with a given name
If a user knows a channel’s name, can he join it?
What’s the difference between a MultiPipe and a UniPipe
Uni-Pipe is a direct pipe from user to user. A multi pipe is what we would call a public chat room.
Is everything I send to the channel sent to everybody?
Well, yes and no…
In the end, the server INITIALLY is quite dumb… but it provides a lot of opportunities.
Clients can send commands to the server, the server receives data and decides what to do with it.
- If Alice sends a “say”-command (literally speaking) on a channel she joined, the server side module will decide to forward the message to all users in the channel.
- If Alice sends a “leave”, the server would notify all others of her disappearing.
- If Alice sends “Say ‘Hi’ to my friend Bob” (talking to Bob’s pipe), the server would forward the message to Bob, notifying him that it was Alice
Well, finally, and how does it really work? Does “Push” create incoming connections?
Simple answer: Its not “really” push, so no incoming connection.
Actually, the idea behind the client-server communication is quite simple:
So, the CLIENT always opens the connection and the server just has the option to either keep the user waiting or send him something, immediately.
And then it is up to the client side JS framework, to deal with the data.
In a default config, this “long request” will be refreshed every 25 seconds, as a keep-alive to the server. After 40 seconds of no answer, the server will consider a user as timed out.
APE is cool! APE is fast! APE is fun! And there is some documentation…
At the time of this writing (March 2010), getting into it is a little bit tideous because of the fact that some documentation between the APE comics and the API description is missing. Thats why I provided my notes, hoping it will help some-one.
From what I learned so far, APE is providing a great base for getting your stuff done.
All the functionality that you can find in the demos MAINLY relies on heavy clients, while the server is just passing on messages. However, you can put additional logic into your server, it can talk to a MySQL DB, provide authentication, you name it. You just have to do it.
So, APE provides everything you need to get your real time application up and running, you just have to define the “protocol”, being the commands the client can send to the server and what the server will do with it.
And, hey, come on, seeing stuff being updated directly in your browser as it happens, WITHOUT FLASH, is just awesome 😉
The only thing that really sucks about APE is the fact that is only supports MySQL.
Support for a nosql database like Redis would be really cool.
Great article, I’m currently on the same way to understand all the commands, the protocol and so on.
I need that my server control everything so I’m defining commands that are intercepted by a server side script, which is also listening too as \client\ of the APE.
I write all the message received in a ring buffer (FIFO) and I forward each processing of message to a normal PHP script, which sends a JSON Object to the APE on the originating channel of the message.
For the moment the script client of the APE is 5 line of code script which just forward request to php, which is also in PHP (but running without timeout as CLI), but I’ll release a Qt C++ Class for the Ape that I will also use too as wrapper. C++ app is in my mind more reliable for this task than a notimeout php script. And I love C++. 😉
I will release soon my PHP Class to work with the APE, and in a little bit more time my PHP Framework used for a webapp I’m working on for 2 years (but not released for the moment, I always need to work for real companies and the school, that makes slowing down personal projects).
Thanks!!! This is really helpful as I’m investigating APE myself at the moment.
Looking forward to see what you build with it!
daminetreg – You are making a Qt client? For serious? That is awesome!
I was about to jump off the deep end and make one myself, but… Would yours be publicly available someday?
Sorry I come a little bit late. ^^
If you can wait 2/3 weeks normally I can send you a working version of a Qt client for the APE.
I’ll post there when I will be finished. ^^
Kindest regards. 😉
It was really helpful. Helped me cleared some doubts on pipes and channels
Thanks =) that was a great article.
I have one more question, maybe you already have the answer.
I was playing on the chat demo and noticed that there are ajax requests every few seconds. Firebug shows the params of each GET/POST ( the things I wrote on chat ) and also shows the response( every new content ).
APE’s documentation makes me think that there wouldn’t be so many ajax requests, only callback functions that would be called by server events.
I know POST should be used to send commands to server when we write a new message. What about the frequent GET request?
Wouldn’t this requests make the chat works like any other simple ajax chat without APE?
Did I understand something wrong?
great post! I’m currently trying to discover how Ape works, and I think its major disadvantage is its lack of documentation, so I appreciate what you wrote!
@carla, I’ve been wondering the same thing. to what extent ape differ to Ajax. My assumption was that client will send POST to server, server will respond from time to time with updated event, without any GET request to server by client. Client leave the channel with another POST. this assumption doesn’t seem to be valid since you’ve observed so many post/get (post is OK since you’re updating your chat) between client/server.
I’m not a serious coder.. I’ll only be running demos come with Ape package, so very limited view in what APe is doing inside. Appreciate response from someone more knowledgeable.
I saw you at StackOverflow (http://stackoverflow.com/questions/6513367/what-are-the-main-differences-between-ape-and-node-js), getting to know that you’ve been working on APE.
They claim ~100K concurrent users. However, I also agree with you that the documentation really sucks. I have a post regarding the use of APE for my application, but I just don’t know how to get started. Please help me out by giving me some suggestions at:
Thank you very much.