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).
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!