For the last few apps I‘ve been working on, I’ve used Parse.com as a backend, allowing for syncing data between app and website/cms.

For the most part, it has been an excellent experience, and I'd recommend it to anyone needing a hosted backend solution for a web, desktop or mobile application. There are however some gotchas which you may need to be aware of …

1. Relationships

As in any other relational system, there are 3 types of relationship 1:1, 1:n and n:n.

The main issue is that many systems (for instance Core Data) use inverse relationships to ensure data integrity (and for speed of lookups), but Parse only requires one way relationships. The upshot of this is that when syncing, the client library needs to create any inverse relationships. In practice, I found it easier to use Cloud Code to set up the inverse relationship with the afterSave hook. Generally, though, this is a real PITA!

2. Data Portability

I've done a few data migrations with the Parse Data Browser - from one account to another, duplicating for testing etc, and it is quite simply horrible.

Export

The export is, on the whole, pretty good - it allows us to get a fairly good output of whatever data is in the tables.

That however, is the problem, its only data that is exported. I suspect that because Parse's data storage is supposed to be schemaless, when the data is exported, it only exports the data and not any sort of schema - so for instance, if you have an empty table, the exported JSON is also empty.

This is a big issue because Parse classes do have ‘schemas’ - there are columns, with types which may well match those in your client.

So for getting your data out of Parse, it may well suffice, but if you're doing that in order to migrate it or duplicate it, its really not adequate.

Import

Import however is a whole different story.

1. Bulk import - I want to be able to import several json files at once, and ideally have it take the class names from the json file name.
2. Incompatible exports - You can‘t import the Join json files created by Parse export, you also can’t re-create the User, Role or Installation classes from the exported JSON.
3. Importing into existing classes - the User, Role and Installation classes are special Parse classes, so its perhaps no surprise that you can't create these by importing the JSON; allowing you to import additional rows into a class from JSON or CSV would solve this.
4. Incomplete schemas - because there is no schema in the export, if there is no data, there is no schema, this is true if the expoted column is empty (undefined) for all rows, or if there are no rows.

Answers?

• Many of these issues are to do with the way the Data Browser works and could be resolved by improving that, or providing desktop equivalents, using the REST API.
• Others could, I imagine, be solved by exporting a schema.json file with the data export, which describes all your classes, which is then the first thing that's read in, and helps recreate all your classes.
• Ultimately, though, every time I've gone through the process its been for one of two scenarios:-
  1. I've been working on my own Parse account and now need to migrate to a client account.
  2. I've been working in a development environment and now need a clean live environment, whilst maintaining the development one for further work, or vice-versa.
• This suggests that the most useful thing Parse could add would be a simple “duplicate app” function - duplicate in my account or duplicate to another account. This would remove 90% of the requirement I've had for exporting / importing.

3. Cloud Code

Cloud Code is really useful and opens up a huge number of possibilities for working with Parse but its a real ball-ache to work with!

• The development process is hampered by not quite knowing what the platform is that its running on and what that platform's capabilities are. What would help enormously would be some sort of black box VM type thing that emulated the cloud code part of Parse that you could run locally.
• This means that the most reliable way of testing is to do some development work locally, unit test where possible, deploy and then test with Parse. But that all takes time and delays of that sort are the enemy of efficient working especially for developers.
• Particularly becuase of the issues with duplicating the app environment in Parse, its very easy to get sucked into a situation where you're trying to fix something on a live data set - very very bad practice; but if its going to take you best part of an hour to duplicate the data in its current state to a dev environment, that is exactly what will happen.
• Timeouts - Parse has a very short timeout for cloud code functions (about 3s), which means for instance that you will need to work with any longer running functions on client side applications (eg updating a series of records).

Conclusion

Although this might seem like a big old whinge, I‘m posting it because I think Parse is a great product and it, and its ilk, represent a huge boon for developers who want to focus on the app they’re building and not the infrastructure that supports it.

Cloud code certainly allows us to work around some of the issues, but there are still a number that make working with Parse more difficult than it should be. I really hope that we see these things resolved soon, so I can get on with just building apps and not working around issues.