BaaS — Contemplating the new Multi-tier ParadigmPosted: February 9, 2013
I reluctantly adopt so-new-the-paint-smells neologisms, and “back-end as a service” doesn’t seem like a winner to me, but nevertheless, I am using this concept, if not word, more and more in my consideration of industrial strength architectures for device-enabled, “web-scale” Apps.
One of the early major changes to the way software got built for the enterprise, as the desktop became a major computing resources to factor in overall application design, was the movement toward well defined clusters of functionality as separate entities that were ganged together for solutions. This is so common now as to be accepted without much thought, but as I consider the best way to develop and deploy a mobile app with significant back-end and administrative functionalities, I find myself again thinking about what clusters of functionality do I want behind my UX. And today, I find some very different choices. This post is about those choices and what makes sense for a particular use case.
For a tablet App that will have students for users (TestTakerPro), and that is part of an overall service that includes desktop-users (native or browser) that are Teachers (TestMakerPro), and that also requires significant back-end and administrative functionality (managing TTP, TMP accounts, securely storing exams and exam results for distribution, collecting and processing test item and exam performance data, visualization and reporting of exam results, etc) (the AssessmentProSystem), I began my quest for an application architecture by considering a “roll your own” approach using Amazon Web Services (and their ios SDK) and concluded that a) it could do everything I needed, using just a couple of services; and b) it would not be too expensive or difficult. Further, with Android SDK for AWS, I’d have no barriers to a future “alternative tablet implementation” should the market ever make this attractive 🙂
Alas, there are many choices with different learning curves, run-time costs, ease of integration, etc and with a limited (time) budget I thought I’d try a more modern approach. I’d read that parse now has over 50,000 apps using their offering, they have expanded to desktop and Android support, and the iOS implementation looks very true-to-spirit of Core iOS services. A good source of ideas and alternatives can be found on Ray Wenderlich’s site in these tutorials:
- How To Easily Create A Web Backend for Your Apps with Parse
- How To Choose the Best Backend Provider for your iOS App: Parse vs Stackmob vs. Appcelerator Cloud and More!
After some consideration (e.g. using app Mobi for user / app data and AWS directly for “files” (test and item performance data, test results) I have decided that “Parse” will make my live easier and looks to be a very quick and easy step to a suddenly intelligent and scaleable App-universe.
I plan to use Parse for just a couple of simple things initially:
- repository that knows all users (test makers and test takers) that want to “register”;
- place to store test results and test performance (event logfiles) for registered users (and where the post-exam-processing modules can grab them for processing); and
- in the future, a place for TestMakerPro to send new exams, and from which TestTakerPro users can select (if eligible) exams.
I have taken the first step and found “parse-enabling” my app to be straightforward. I’ve connected to the back end, and now need to adopt some form of their standard register / sign-up / user identification scheme. Posting my log files and test results from TestTakerPro should be simple enough, once that bit is done.
With luck, it will be done with a few hours of work, but sadly, that might take a week or more to find that time. I am thinking something like this…