These last few weeks I have been writing here and posting elsewhere about Parse, a service that stands up a simple backend for mobile application developers to connect to their apps. There are lot of good things that can be said about Parse. Unfortunately, it is based on a sub-optimal development model: dumb server / smart client. For the purposes of this article I am defining this development model as putting all or most of the validation on the client and reducing the server to little more than a thin layer over the database. Some of my more experienced readers will have their own ideas as to why this development model is sub-optimal, but for the rest of you I am going to go through the two that I see as the most important / relevant for today’s mobile development landscape: inherit functional limitations and slowed update cycles.
Parse does a great job and is a joy to work with, as long as you are doing what it was designed to do: authenticate users and store some data. For instance, try to pull a random object from your Parse data store but ensure that you get the same object on every client while making only one network request per client; hint: it is not currently possible to do with one network request and you will have to make at least two. In my experience, the best network request is the one that was never made. Once you send data over the air, the integrity of your user experience is out of your control and we all know how unreliable 3G can be. Getting a little more specific to Parse, you are currently placed into a higher pricing tier if you make over a certain number of requests to Parse.
Let’s be real here. If we are talking about mobile development projects, then we are most likely talking about iOS. Unfortunately, getting an update to your iOS app approved can take weeks and the situation doesn’t look to be changing soon: Windows 8 RT is adopting a similar review model and Android developers who target Amazon’s app store are subject to a similar review period as well. That’s bad enough taken alone, but consider that most software has bugs and that there is a correlation between the complexity of the code and the number of bugs in that code; that is why we try to follow KISS (keep it simple stupid). Given that, there is a clear incentive to keep the code on the client as simple / elegant as possible. However, running a dumb server and forcing validation on the client prevents that in most cases; your client code will have to take on most of the validations that the backend code would have had, thus making it that much more complex. Imagine a bug that you can’t get a patch out for in less than twenty days but worse still you can’t guarantee that all of your users will update as soon as possible or even at all. With a real backend API you could make the fix and the bug would be taken care of for all users in most cases.
These are real risks and either of them can derail your project. Should you just avoid these type of things wholesale? Maybe… but there is certainly an argument to made for extremely low budget projects or prototypes. Let me know what you think on Twitter or Google+. Also, if you have not already, pick up your copy of Code Journal today either from the Mac App Store or direct.
