Transition App From Parse.com

2
votes

I have built several apps using Parse.com and one has just been promoted to a funded product. The app (a social network) is fairly complex as far as Parse implementations go. It has:

  • Near real time chat
  • A newsfeed
  • Lots of cloud code
  • IOS client and Android starting in the next couple weeks

I have experienced a lot of the typical Parse pitfalls (timeouts,exceeded query breadth, etc) and that is only with around 2k users. With our new funding it is likely that we will jump to at least 40k users in the next year which will amplify the issue.

It all comes down to the fact that I think we need to move away from Parse but the question is how avoiding downtime.

How have you transitioned live applications from Parse.com? Any gotchas or lessons learned?

My initial thoughts are to implement a thin API (using an separate server) to abstract the client interactions away from Parse so I can transition the app. Anyone taken this approach?

EDIT:

Given the fact that Parse is shutting down this question is relevant for more people so I thought I would add what I ended up doing.

We ended up building the app on NodeJS/Express/Mongoose with a Mongo backend (using Compose.io). If you can write cloud code you can write for Node and Mongo is what Parse uses. My analysis of the options were that it would take a significant amount of time to create some sort of middle layer just complicating things. I had the new version together in about 3 months and it is live with a much larger and very active user base.

1
androidiosapiparse-platform
As someone who hopes to have this problem in the future, have you scaled up beyond the free 30req/sec level? What problems have you seen? - mbm29414
If we have gone past the 30req/sec it was only very briefly. The issues we are seeing mostly have to do with populating a newsfeed using complex rules and the timeouts that parse imposes on all requests. - 1kmonkies
Have you considered performing some of the more time consuming methods on another server and uploading the results. (For example running them as C# queries and uploading the results). This may not make sense in many instances, but it has helped us immensely in short term projects where we want the ease of use of the iOS/Android APIs, but we have hit a brick wall with cloud-code timeouts. (Not a great long term approach obviously, but good if you don't have excess development time). - ardrian
@ardrian Your suggestion is my quickly approaching 'plan b' but I'm sure the same issue with timeouts is right around the corner for us as well (we already have some but it will get worse). At this point I'm thinking we either jump to a totally new API right now or stay on Parse and plug up the holes we have at the moment. I don't like either option! - 1kmonkies

1 Answers

1
votes

I would suggest you to first take a revisit on your data model. An improperly designed data model will cost you a lot. When designing data model, few things to consider are:

  1. You have huge data storage limit, but lesser query execution limit. So if you can properly manage, it's better to have some redundancy to reduce query/requests to server.
  2. You must try your best to avoid batch data insert/update operations by having a model like that.

And regarding migration, i think as you have cloud code, you are comparatively safer.

  1. Make sure your data is migrated. This will be a bit pain and may take some additional efforts on ensuring integrity.
  2. Once data migration is done, make your cloud code just as a wrapper. Have your own api's on your own server and then make request to these api's from cloud code using Parse.Cloud.httpRequest and serve the response.
  3. Release an app update so that new users can directly interact with your own API's.