Build vs Buy: Appcelerator Cloud API Case Study

A lot of times a project at hand has some components that can either be built from scratch, or a ready-to-use solution can be bought from a 3rd-party vendor. For example, there’s lots of ways to build a blog or a CMS, but most likely you will just use one of the many solutions already available on the market (such as WordPress).

One of the projects I have at work has a star rating component, and we had a vendor in mind – Poll Daddy (interestingly enough owned by Automattic – the creators of WordPress). It’s a super quick and easy JavaScript-based solution, that allows users to give a rating from 1 to 5 stars. It costs about $900/year for unlimited ratings, and requires virtually no development effort (aside from copying&pasting the script code).

Then, someone suggested we user a “cheaper” option – a rating component built on top of Appcelerator cloud services. Usage of the API is apparently free for up to a certain call volume (and who doesn’t like free?). I’m not opposed to using a better solution, so I decided to look deeper into this platform and what it offers.

Here’s essentially what it is: Appcelerator Cloud Services provides a back-end infrastructure mostly targeted towards mobile apps that use its Titanium development platform. The API provides a layer of methods and services that allows developers to build apps without worrying about server-side infrastructure. There are pre-built components that can allow for faster development, one of the components is Ratings and Reviews.

However, it’s not a plug-and-play deal. In order to achieve the star ratings functionality that we need, there are multiple implementation steps and gotchas:

  • We would need to create a list of products we want to be rated as Custom Object type in the API
  • To submit reviews we’ll have to know which product they apply to, so we’d have to map Custom Objects to products, probably performing a “GET” call to fetch Custom Object data and map it to products
  • We’d need to create a mechanism to prevent duplicate submissions (session or cookie or IP-based). Appcelerator asks for a user_id value to be specified whenever a rating is submitted, so it means we would have to create and work with a User object as well
  • Submitting a rating requires the user to be logged in – another API call
  • It also turns out that PUT and DELETE API methods trigger an XHR error from 3rd-party domains. This is resolvable by adding headers (Access-Control-Allow-Origin per CORS specifications), but will require additional settings adjustment on the server-side
  • And finally, any custom development will need to be thoroughly QA’d – which adds effort and time

I’m sure the Appcelerator cloud API is a great solution for certain cases, but for a super-simple component in my scenario it is much quicker and easier to go with a pre-built solution that satisfies all of my requirements.

Funny enough, we had another “build vs buy” discussion at lunch with Mike today, and thought that 80/20 rule can be applied to this problem: if spending 20% of the effort yields you 80% of result, that’s what you should go for.

Curious to hear about other build vs buy examples, so leave your notes in the comments!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s