The dirty little secrets of transitioning away from Parse

How can I make my mobile app work again?

Mobile app developers are grappling with Facebook’s decision to shut down Parse. Multiple discussions have sprouted up, so have multiple database migration tools. Like most things though, the devil is in the details. Almost no one is talking about the big elephant in the room which is “How can I make my mobile app work again?”

Below is a discussion of what any migration effort could really mean.

1. Getting the data is pretty easy (but the bare minimum)

Along with their announcement itself, Parse already provided everyone with an export to your own MongoDB database migration tool. This is the least they could do, that allow us to at least get all our installation data (in other words our user data) out from their cloud systems.

This does not answer the question about making my mobile app work again? In fact, Parse’s own migration guide clearly says that the migration specifically does not support either Analytics or Push Notifications, so there’s work to be done in order to stitch everything up.

In order to tackle the real issues of app migration, there are clearly two distinct user groups of Parse to consider:

a) developers using Parse ONLY for Push Notifications and

b) developers using Parse as their full backend service

Let’s breakdown the issues involved with each of these two groups.

2. Developers using Parse ONLY for Push Notifications

The primary issue to consider here is how can I maintain continuity for my existing and new app users during the transition period. Is this going to be possible at all?

The most common scenario when using Parse for push notifications is to use Parse channels or custom variables you can set on Parse installation objects in order to segment your users. For example, a sports score app might have a channel for each team so that after a game ends it can send the score to all the team fans.

As part of the data export, you do get the channel information in your data, but app user continuity cannot be maintained if:

1. I can’t reliably match a mobile app user to the corresponding installation object data on the server? For example, on Android you will need to update your app to use your own GCM sender ID, as Parse’s will no longer work. This means the GCM tokens imported from Parse will also not work with another provider if using Parse’s sender ID.
2. I not able to set and unset channels (as well as other custom variables) within my mobile app to the corresponding installation object on the server.

Needless to say the key to identifying an installation object is either an object-ID or a device-ID, both of which are Parse created identifiers. There’s engineering effort involved in not only extracting this key value, but more importantly finding an easy enough way to use either of these values to identify and update the correct installation object in order to keep all your data in sync with continued use of your mobile app.

Irrespective of the specific details of the technical implementation, a full solution to migrate out of using Parse for your push notifications include in the least:

1. a tool to migrate your data, inclusive of channels and installation object variables
2. a mobile SDK that you can replace your existing Parse mobile SDK with, that is capable of not only matching the current app user to the corresponding profile in the server database but also providing the API function calls to be able to set and unset these channel and custom variables. The SDK should be able to handle both your old app users and new users (downloads) that will come with your new app version upgrade.
3. a server side API that mimics Parse’ server side API to be able to send push notifications to different channels and installation segments using custom variables.
4. a phased transition process, which for Android means almost immediately updating your app with a new SDK simply to gather new tokens. Only after having done that for a reasonable amount of time will you be able to import to a new provider and switch over. You will still lose continuity for those users who didn’t update your app.

Clearly, the best technical solution will be the one that reduces the amount of code changes and clearly manages this transition phase to provide your users with the benefit of a continuity.

3. Using Parse as your full backend service

This is a lot more troublesome. While it’s technically possible to reasonably seamlessly migrate away from Parse for push notifications, it’s much harder if you depend on using Parse as your full backend stack. Many alternative lists have began to sprout up, including this one — Parse alternatives at Github.

The issue for developers with any serious alternative is that there’s just a lot of work to do — not only development but also more software testing to get everything going well. There are multiple comparable cloud services including Google’s Firebase as well as the slew of services available with Amazon Web Services (AWS). Every platform has it’s own paradigm’s to learn and code to be migrated to…and if you are a developer in this boat it’s best to take some time to:

1. breakdown and isolate all your Parse usage scenarios
2. for each of these scenarios (backend services used) decide on the best alternative whether to bring in-house into your own servers, or use alternative cloud services.

This splits the problem into smaller manageable parts and will eventually help you make the best design and migration choices. Facebook has given us some time, no need to rush tomorrow into a hasty solution.

It’s important to not constrain yourself by thinking if you rely entirely on Parse that you need to find another single vendor with which to replace everything. It’s common, in fact even desirable to replace your Parse services with a combination of two or more services. You’ll find that the generalist one-stop shops may require you to write more code on top to get your desired functionality, whereas more specialized services might provide what you need out of the box.

4. Wait, there’s more…

It’s horrible to be left in the lurch like this and after the news settled, the first thought that came into many minds is “How can I prevent this from happening to me again?”

While we cannot control what any business does with its services and products, it’s always a prudent choice to pick a vendor whose primary business is providing services to make your apps better, not one who also provides these services but has its primary business doing something else.

Over the next few weeks we will be providing more resources for the Parse community, including migration tips and tools for developers in both of the above groups. Stay tuned.

Obligatory Disclosure: I am the co-founder and CEO of CleverTap, which is an App Analytics and User Engagement platform. You can use CleverTap to engage with your users via push, in-app, email and web notifications.