After 4 years having a slow reload-frame-based chat (also called “codename Neandertal”) tilllate has launched a new, state-of-the-art chat. In addition of average-joe chat functionality you can also open your own private rooms and invite your friends there. I spoke with Ciprian, our developer of this product.
How successful is the new tool?
The tilllate members seem to chat a lot in the new chat. Almost 100 000 messages the 1st day, and 125 000 the second day. I think it’s quite a lot. But there were also bug reports. Really weird ones: “There’s something wrong with tilllate. They don’t have the old slow and ugly chat anymore. This must be an error! With such a cool chat I am going to spend even more time on tilllate. That’s bad for my career.”
A new thing for me was to hear somebody complaining the web it’s too fast (“Es isch fast zu schnell!!“).
What was your role in the development of the chat?
It was my job to provide the architecture of the whole application, and then implement everything. Starting with the database structure and ending with the server and client classes. And of course test everything.
What technologies have been used for the Chat?
The new chat was a big project. So we started designing the architecture in UML. Both for the server side and for the client side. Then everything was done OO-Programming: PHP on the server, and OO-Javascript on the client. The communication between the client (browser) and the server is all AJAX (no reloads) using JSON. For the database, MySQL transactions proved to be a good choice.
How’s the architecture of the new chat?
The new chat is entirely OO. The 15 Javascript classes (User, UserList etc.) on the client have a controller class that communicates with the controller class on the server (controlling 10 php classes).
What was the biggest challenge?
The biggest challenge it’s the first part: the architecture design. What classes do I need on the server, what classes do I need on the client? How should the database look like? Do I need transactions? Is that fast enough? Once we have done these things it was a peace of cake. 80% of the work was done. We thought. Then we found out we still had 80% work to do. 😉
Actually, there were several iterations of refactoring: The final object model does not look anymore like the initial one.
Any tip about Javascript and AJAX you would like to pass to our readers?
Everything is about speed. Make AJAX requests as fast as they can be. Avoid too many requests, however. Avoid transferring irrelevant information. We don’t send the whole user list on every request. We just transfer the change events (add user, remove user). JSON is a good protocol and natively supported in Javascript.
Why and where exactly do you use MySQL transactions in your chat and why was it a good choice?
In order to make the chat faster, every chatroom knows the last message ID it was sent there. This way sending a message means more then just inserting a new row. Also when you open a new private chat, there are more things to take care of (creating the room, notify the user, etc.). With transactions we have atomicity: if anything goes wrong, the message is not sent, we notify the user and perform a ROLLBACK => no inconsistent state for the DB.
I like the way you make the chatting faster. I will surely employ this idea in my other applications.