3 ms·

While Parse solves a huge problem, there is also a catch - You are locked into an ecosystem where you have no control over your codebase incase of an Emergency.

by neya 14y ago

While Parse solves a huge problem, there is also a catch - You are locked into an ecosystem where you have no control over your codebase incase of an Emergency. For example, Parse's recent downtime made developers helpless as they had only two options - Re-write the entire app, or wait for the downtime to get over. So basically, its a trade-off between convenience and reliability. Choose wisely. No, this is not meant to discourage you from using Parse. If it solves your needs, then go for it, but always have this catch in mind and preferably have some kind of a back up plan incase Parse goes down along with your app.

chresko 14y ago
I chose to use it because I'm not a very good backend developer (my bad) and needed something up and running quickly. But I agree that it's probably not a good longterm solution.
jawngee 14y ago
I'm working on that problem: http://github.com/jawngee/modelkit http://github.com/jawngee/modelkit (iOS/Cocoa)
- flocial 14y ago
  Have you looked at FTASync?
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).

by neya 14y ago

chresko 14y ago

I chose to use it because I'm not a very good backend developer (my bad) and needed something up and running quickly. But I agree that it's probably not a good longterm solution.

jawngee 14y ago

I'm working on that problem: http://github.com/jawngee/modelkit http://github.com/jawngee/modelkit (iOS/Cocoa)

flocial 14y ago
Have you looked at FTASync?

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).