Yesterday we went through to Stellenbosch for the launch of the new MXit API . We’ve built quite a few campaigns on MXit in the past, but have always been somewhat frustrated by the limitations of the system – if your campaign elements don’t fit into the options of portals, bots or chat zones, you end up trying to shoe-horn or change them to fit in with what is available. I’m always banging on about technology being an enabler and not dictating the what and how of our interactions, and this is a perfect example of that. So having an API into the MXit platform is something we’ve been looking forward to for some time.
The actual launch day was a strange mix of press, entrepreneurs, business owners and developers – strange because it meant that each presentation was only really talking to half the audience at any one time. I think the event could have been a lot shorter and delivered more value if there had been two distinct streams – business and development.
For me the two sessions that were the most interesting were Adrian Frielinghaus from Blue Leaf Games, talking about some of the learnings that they had building a multiplayer game in MXit. It wasn’t a technical session at all but he touched on 2 incredibly important points: how do you build behavior into the game that builds retention and ultimately money, and how do you prepare for the scale and magnitude of numbers that you may attract.
For the developers in the room the session after lunch was the one we were all looking forward to – building an actual application live on screen. Gustav Mauer started by taking us through the technical requirements for using the API and the reasons for going the way that they did. Bad news (for me) is that your development and hosting all happens in a Microsoft environment – Visual Studio Express 2008 or greater with the WCF framework, deployed onto a Windows server. The reason for this is twofold: existing developer base in South Africa and the performance of Net.TCP over the alternatives. Your application will send to, and be sent messages from, MXit, so it needs to be a protocol that supports full-duplex communications. The good news is that this is the first API that they are launching, other languages and frameworks will be catered for in the future.
On the face of it, the API interfaces are incredibly simple: connect, disconnect, send a message, request a payment. MXit can send back a message and let you know if payment went through. There are a couple of others, but this is the core that will get you going. I was initially a bit disappointed that that was all the API provided. It seemed that there wasn’t a huge amount more that you could do than if you simply asked MXit to proxy an external HTML page into a portal/contact for you. What would have been nice was to be able to interact with the user in some way – access their images, status messages, friends – but I can understand why we can’t. With the user base that they have and the privacy issues that they encounter, giving developers easy access to the user detail could easily be abused. I’m sure that all of these considerations will be dealt with in time, but for now it’s an important step forward in giving developers a solid way into building the interactive experiences that they want within MXit. There’s a lot happening in the background that the developer doesn’t have to deal with – dealing with caching, images and the actual MXit protocol – but all considerations for the guys building the API. Slow and steady is fine.
The day ended with a Q&A session, some interesting questions from the floor. The one that I think was on everyone’s mind was how much traffic/data will applications potentially generate? It’s a bit of a how long is a piece of string question, the best response we could get was to host somewhere that can scale, and scale fast. Adrian shared some info on how their app is deployed – because it is database intensive they have 4 heavyweight DB servers, two of which are currently carrying the load of their 150 000 users. His presentation from he day has some graphs on the number of users they see on a day to day basis, which you could probably use to load or performance test your application ahead of launch.
While the API isn’t the panacea for mobile and MXit, it has opened up the platform a lot more than in the past – with the right idea (and a willing .NET developer) you can build some really engaging experiences (and for the marketers out there) some real participation with your brand.
After reading this, i have got to say, i am really surprised at the way they implemented their WCF API.
I for one am not convinced by their reasoning.
There are quite a number of ways they could have developed their API – using WCF – that would have made it accessible to almost every language/framework while still supporting asynchronous callbacks 
Not to mention that this implementation seems to completely ignore REST and all its yummy goodness.
It just seems odd that they would limit the availability of their services, which also limits the potential for innovation, from the get-go when there is no real reason to do so.
Keep in mind though: i wasn’t there and could easily be missing a huge bit of the picture
Just going on what i’ve read here.