[imownbey]

The iPhone client was really good and really solid. Unfortunately we had to migrate off of Parse though because of pretty consistent downtime and really slow speeds. It wasn't unlikely for Parse to go down for at least minutes at a time once a day. Migrating off of it is not easy because you have to then replace the really solid client which can take some time to reproduce some of the features you have ended up relying on.

The dashboard also left a lot to be desired. It limits how many tables it shows on the left so you end up having to hack the URL. I believe they finally offered a "fullscreen" mode rather than having a fixed width and height which is nice. Basically we would have to drop down to the Ruby client to audit the data often which isn't the worst.

Parse would also just write random blank rows all the time whenever we did concurrent writes (this is a known bug https://www.parse.com/questions/duplicated-empty-objects-cre...). They have just moved over to the Facebook Developer bug tracking which is pretty awful as well.

Parse was really good to prototype on which was nice, but it is extremely likely if you want to launch anything to the app store and don't want to deal with downtime you have no control over you will need to rewrite it. For this reason I would suggest with just using something home grown.

[csmajorfive]

Hey there, I work on Parse. This is good feedback.

Improving reliability is our #1 priority right now. The bulk of our team is solely focused on it. We've made some good progress and hope to have things in a much better place by the end of the year. You can follow it all on our status page. We try to be very transparent with post mortems and such.

That bug sounds nasty. I'll take a look to see if it's still an issue but I believe it was fixed a while ago.

The Facebook bugs flow has its pros and cons but I believe it's been great for our community on balance. We have an awesome team of folks triaging and repro'ing bugs and interacting with the community thanks to our integration there.

Drop me a note at [e-mail] if you have more thoughts about the dashboard or anything else.

[imownbey]

So I would recommend using Parse after the end of the year once they figure out their reliability. Infrastructure as a service that is in the process of improving reliability is not very confidence boosting, though.

But I do appreciate that yall have started posting on status.parse.com! That is a major improvement in the right direction.

[csmajorfive]

That's a totally fair assessment.

I just mean to say that we've prioritized it above all else and are really crunching to make it a non-issue for our developers. Our traffic has exploded in the last year so we need to rework some things.

[themonk]

If object goes to MySQL, hire me to scale.

[LazerBear]

I always think it's admirable when a CEO offers his help in forums.

[altyus]

To address the "moving off of Parse" comment: The way I've dealt with this is to use the Parse REST Client instead of the Parse SDK. That way you're object model isn't tied to parse PFObjects and you can swap out the Networking layer if you choose to move to another vendor. If you control the full stack, you can even model your backend to more-or-less mimic Parse's Rest API.

[imownbey]

Yeah in retrospect we should have definitely done this. Although it causes a significant trade off to prototyping speed. I am not sure if its not just worth using your own API at that point.