2 ms·
Writing a full backend is serious work and it will cost you significantly in terms of time to market. For a green field app that doesn't require a companion we
by flocial 14y ago
Writing a full backend is serious work and it will cost you significantly in terms of time to market. For a green field app that doesn't require a companion web service it's still very attractive. Parse runs on AWS so if you build your backend on AWS, you still need to build a failover mechanism to handle that to be more reliable than Parse.
My main concern with the Parse SDK on the iOS is the lack of a clean model layer (and no, subclassing PFObject is not allowed) that would allow you to rip out Parse once you outgrow it. The way I understand it is the Parse SDK more or less encourages you to embed your models and business logic into the controllers as far as MVC goes.
It would be nicer to have a smoother transition path. A way to use CoreData as a local storage that seamlessly uses Parse would be a great option.
Minor gripes include the lack of a bulk delete api. Although there is a bulk save function so you could use that to soft delete.
However, with all that said, still seems like a great option even though the migration to a self-managed backend seems pretty rough (to maintain data integrity).