Creating a wrapper for BeaaS (Parse/Stackmob/...)

Question

I'm currently developing an app using Parse and I'd like to start abstracting their SDK as I don't know if and when I'm going to replace their backend with another by other provider or by ours.

Another motivation is separating issues: all my apps code will use the same framework while I can just update the framework for any backend specifics.

I've started by creating some generic classes to replace their main classes. This generic classes define a protocol that each adapter must implement. Then I'd have a Parse adapter that would forward the calls to the Parse SDK.

Some problems I can predict is that this will require a lot of different classes. In some cases, e.g. Parse, they also have classes for dealing with Facebook. Or that the architecture in some parts can be so different that there'll be no common ground to allow something like this.

I've actually never went so far with Stackmob as I am with Parse so I guess the first versions will share Parse's own architecture.

• What are the best practices for something like this?
• Is there something like this out there? I've already searched without success but maybe I'm looking in the wrong direction;
• Should I stick with the Parse SDK just making sure that the code using it is well identified and contained?

Answer 1

I'm the Developer Evangelist at Applicasa. We've built a cool set of tools for mobile app developers, part of which includes offering a BaaS service that takes a bit different approach compared to Parse, StackMob, and others. I think it provides a helpful perspective for tackling the problem of abstracting away from third-party SDK APIs in a way that would allow you to replace backends by other providers or your own. /disclaimer

Is there something like this out there? I've already searched without success but maybe I'm looking in the wrong direction

While there are other BaaS providers out there that provide similar and differentiating features, I'm not aware of a product out there that completely abstracts away third-party providers in an agnostic manner.

What are the best practices for something like this?

I think you already show to be on a solid footing for getting started in the right direction.

First, you're correct in predicting that you'll end up with a number of different classes that encapsulate objects and required functionality in a backend-agnostic way. The number, of course, will depend on what kind of abstraction and encapsulation you're going after. The approach you outline also sounds like the way I'd begin such a project, as well—creating classes for all the objects my application would need to interact with, and implementing custom methods on those classes (or a base class they all extend) that would do the actual work of interacting with a backend provider.

So, if I was building an app that, for example, had a Foo, Bar, and Baz object, I'd create those classes as part of my internal API, with all necessary functionality required by my app. All app logic and functional operations would only interact with those classes, and all app logic and functionality would be data backend-agnostic (meaning no internal functionality could depend on a data backend, but the object classes would provide a consistent interface that allowed operations to be performed, while keeping data handling methods private).

Then, I'd likely make each class inherit from a BaseObject class, which would include the methods that actually talked to a data backend (provider-based or my own custom remote backend). The BaseObject class might have methods like saveObject, getById:, getObjects (with some appropriate parameters for performing object filtering/searching). Then, when I want to replace my backend data service in the future, I'd only have to focus on updating the BaseObject class methods that handle data interaction, while all my app logic & functionality is tied to the Foo, Bar, and Baz classes, and doesn't actually care how get/save/update/delete operations work behind the scenes.

Now, to keep things as easy on myself as possible, I'd build out my BaaS schema to match internal object class names (where, depending on the BaaS requirements, I could use either an isKindOfClass: or NSStringFromClass: call). This means that if I was using Parse, I'd want to make my save method get the NSStringFromClass: of the class name to perform data actions. If I was using a service like Applicasa, which generates a custom SDK of native objects for data interactions, I'd want to base custom data actions on isKindOfClass: results. If I wanted even more flexibility than that (perhaps to allow multiple backend providers to be used, or some other complex requirement), I'd make all the child classes tell BaseObject exactly what schema name to use for data operations through some kind of custom method, like getSchemaName. I'd probably define it as a BaseObject method that would return the class name as a string by default, but then implement on child classes to customize further. So, the inside of a BaseObject save method might look something like this:

- (BOOL) save {
  // call backend-specific method for saving an object
  BaasProviderObject *objectToSave = [BaasProviderObject
                                      objectWithClassName:[self getSchemaName]];

  // Transfer all object properties to BaasProviderObject properties
  // Implement however it makes the most sense for BaasProvider

  // After you've set all calling object properties to BaasProviderObject
  // key-value pairs or object properties, you call the BaasProvider's save
  [objectToSave save];

  // Return a BOOL value to indicate actual success/failure
  return YES;  // you'll want this to come from BaaS
}

Then in, say, the Foo class, I might implement getSchemaName like so:

- (NSString) getSchemaName {
  // Return a custom NSString for BaasProvider schema
  return @"dbFoo";
}

I hope that makes sense.

Should I stick with the Parse SDK just making sure that the code using it is well identified and contained?

Making an internal abstraction like this will be a fair amount of work up front, but it will inevitably offer a lot of flexibility to implement as you wish. You can implement CoreData, reject CoreData, and do whatever you'd like really. There are definite advantages to building internal app logic/functionality in a data-agnostic way, even if it's to allow yourself the ease of trying out another BaaS in, say, a custom branch of your app code to see how you like another provider (or to give you an easy route to working with developing your own data solution).

I hope that helps.

Answer 2

I'm the Platform Evangelist at StackMob and thought I'd chime in on this question. We built our iOS SDK with a Core Data interface. You'll use regular Core Data and we've overridden the NSIncremental Store to persist to StackMob instead of SQLLite.

You can checkout an example of the Core Data code.
http://developer.stackmob.com/tutorials/ios/Create-an-Object

If you want see what methods are being leveraged by Core Data to communicate with StackMob. http://developer.stackmob.com/tutorials/ios/Lower-Level-CRUD-API