Appcelerator + Cocoafish - First Impressions

Appcelerator + Cocoafish - First Impressions

June 10, 2012

In case you hadn't heard, Cocoafish is an application "backend service" in the Cloud, and allows you to build your apps against their API's instead of having to go through the process of buildling your own and hosting them. It's a great idea, and one that has been done before by StackMob and others, but of course for a Titanium developer the most interesting aspect of Cocoafish is that it was recently bought by Appcelerator, who intends to build its API's smack-bang into the Titanium framework.

As someone who got an early invite and has built a client application on this framework already, I thought I'd give everyone a brief heads up of what to expect when Appcelerator rolls it out as "Ti.Cloud" sometime in March or April.

The Pros:

  1. It's quick. That's quick to get setup, quick to build against, and quick to both query and return data. I'd estimate it's saved me about 10-15% of development time so far, and once the API's are built into Titanium directly and I'm more used to building against Cocoafish's "types", it could legitimately save me even more time.
  2. It's nice and standardised... I have obviously used JavaScript to hook into it from Titanium mobile, but I've also written some PHP classes to interact and perform some routine tasks against my CF objects via CRON scripts. Writing the PHP API was a breeze.
  3. I like the way all requests generally bring back the attached user object in question as well. For example, querying photos will always return the basic user information associated with those photos.
  4. It's stable - even in Beta I have had zero problems with uptime or stability. Everything has worked. Nothing to complain about here.
  5. There's no need to worry about hosting uptime, bandwidth, storage permissions, etc. For anyone who has ever managed a large web service system, that's a good thing.
  6. No f**king around with photos. You upload them, they thumbnail, crop and store them in a variety of sizes.
  7. I can imagine all the checkin and place data is very very useful, though I have personally had no need to use it yet.

The Cons:

  1. The backend data entry interface needs work. Specifically, I'm creating a lot of objects in my database to seed it, but each time you add an object entry you have to do it from scratch - if there was some kind of template mechanism or "duplicate" entry thing that'd be great. I have heard that this backend will be updated in the coming months anyway.
  2. There needs to be an overall "administration" account login, whereby I can access CF via the API's and update ANY photo, ANY user account, etc. I have a need to update a custom data field for each of my users every day, based on some outside factors (we'll call the field "rank"). I currently can't do this against the user accounts via my scripts, it requires another object to be set in key-value pairs or custom objects.
  3. Limiting of page sets. I realise this probably has more to do with the platform performance than anything, but I'd really rather not be limited to 100 records. By all means, default to a 100 max unless otherwise specified, but I have objects in CF that I want to update via some scripts on an Ad-Hoc basis and having to do that with paging is just a bit of a pain more than anything.
  4. No real "randomization" ordering. I'd like to be able to set an order parameter of "random", which can't really be done yet. The CF guys were helpful and pointed out a way I could kind of do it by assign a random number to an object and then doing $GTE where clause based on a random input, but that's not really random. It would be good to see a random order set for all API calls implemented.
  5. Cross-object joins. Probably not something everyone would want, but if I have 2 custom objects I would like to fetch at the same time then a cross-object join API call would be great. For example let's say we have a user record, and that user has a role_id attached to it as a custom field. If I want to then fetch a set of custom objects called "role_permissions" and another called "role_details" (both of which have a role_id field) I would have to now make two separate calls and pull back the objects separately. It'd be great if you could do a request for multiple objects that join on the same custom field.

Have you used Cocoafish yet? I'd be interested in your opinions of it so far!