Background

The loss of Parse is a great loss to many mobile developers. Their service allowed mobile developers with little web dev knowledge to leverage a powerful backend that was very easy to integrate into almost any client imaginable. When I first began as a web developer this tool allowed me to deliver full stack apps in a very short amount of time. While I can now build out the back end myself, I will miss that speed, especially when it comes to quick proof of concept projects. I decided to look for an alternative for future PoC work and for porting over any existing applications. One of my first thoughts was to just switch over to Stackmob, but it turns out they were shut down after Paypal purchased them. I see a trend here, two Mobile Backend as A Service companies get purchased by larger companies then shortly thereafter get taken down. Given these experiences I am going to be using an MBAAS that has these two criteria:

  1. Self Hosted Option – While I do appreciate Parse opening up the option to run their APIs on a private server, I would prefer to have that option while retaining the ability to keep it in the cloud as well. That way if they are up, I can use the cloud and if they close up shop, I can just move it to my own server.
  2. Part of Company’s Business Model – It’s seems like after Parse got picked up by Facebook that they did not have goals of adding Parse’s services to the Facebook business model. They, perhaps, instead wanted Parse for it’s tech and talent. I feel that using an MBAAS which is part of it’s owner’s business model is a healthy indicator of long term support for the product.

The two options that jumped out at me where Microsoft’s Azure platform, and Redhat’s Feed Henry platform.  Given that Azure does not appear to have a self hosted option yet we are going to go with Feed Henry. While I will be using their easiest cloud option for this PoC, bear in mind that it can be moved to a hosted server at a later point in time.

FeedHenry, Parse, BlueFletch

Let’s Build an App

Hungry Hungry Henry on Github

Since this app is a PoC with the intent of testing if Feed Henry can be a replacement for Parse, the app itself doesn’t need to be anything too fancy. Instead of going over every bit of the code I am just going to post the sample code for anybody who is interested and mostly focus on my findings.

With a name like Feed Henry, I can’t resist making an app about feeding Henry. For this app Henry is the family dog who loves to beg for food, whether or not he is actually hungry. As a result, he has gotten a little pudgy and needs help controlling his diet. We will build a Henry feed tracking app that will allow family members and dog sitters to track Henry’s feeding time. Let’s call it Hungry Hungry Henry.

Objective C

For this example, our app will be an iOS app written in Objective-C. I started off attempting to build this in Swift but I ran into a few roadblocks.

  1. Feed Henry’s Swift SDK and documentation are not yet completed.
  2. Attempting to use the Objective-C SDK from Swift is very tricky as it is currently not very Swift friendly due to it’s reliance on JSON and dictionaries lacking type checking. More on this later.

My biggest takeaways from using the Objective-C SDK:

  1. Feed Henry requires a bit more to get started than Parse. Luckily though, halfway through writing this they released a huge update to their documentation. Previously many features, such as the data sync feature, only had documentation for Javascript. Now they provide documentation for iOS in Objective-C, but not Swift.
  2. Feed Henry doesn’t seem to have much in the way of support for queries. Data can be separated by users, but other than searching by UID, there appears to be no built in way to easily querying for specific objects. In the demo app for example if I wanted to find all pets with status of Needs Attention, I would have to fetch all pets, then filter through them myself on in the iOS app.
  3. Feed Henry’s API’s seem to all be nearly direct ports of the Javascript version and built entirely around JSON. There is no magic parsing, type validation, or convenience methods. After using this set-up a for a while, I can appreciate the appeal of this simple approach. It allows your iOS models to simply need to have methods that convert to and from dictionaries. While there is this initial bit of boilerplate needed, it makes changing to or from a different backend setup much easier. Porting a Parse app to a backend that isn’t based on PFObject is much more difficult than porting a model layer simply based on NSDictionary. In fact the models and service layer interfaces do not need a single change if the implementation is updated to another backend setup.

In conclusion, yes Feed Henry can serve as a Parse substitute for simple use cases. While it may lack the wealth of documentation and examples that Parse has, it’s documentation has come a long way. While it may not have all of the features that Parse has, for building typical enterprise and business apps it has what matters. It provides the capability needed to add cloud based persistence to your app, with little to no server code or deployments to worry about. Given that the Feed Henry approach doesn’t really lock too much of your native app to their ecosystem, I’ll likely be using Feed Henry for my future basic enterprise and PoC apps, and if it lets me down, I’ll take my JSON and dictionaries elsewhere.



Related Posts

David Newman

David Newman

Lead Developer - David graduated from Kennesaw State University with a Bachelor of Science in Mathematics. David is a cross platform mobile developer who specializes in iOS, but is also very comfortable in Android, and back end web services. His previous mobile and web development work was in the banking, property management, and medical fields.