6 ms·

We used Parse, and (contrary to your suggestion) it helped us get to market much slower and much more expensively. We experienced a hilarious amount of downtime

We used Parse, and (contrary to your suggestion) it helped us get to market much slower and much more expensively. We experienced a hilarious amount of downtime, and hundreds of engineering hours that could have been spent developing features for our users or improving our services were spent working around fatal bugs in Parse, which were usually not manifesting on all instances, which made it very difficult for the Parse team to diagnose them. Fixes for Parse bugs were usually not forthcoming from the Parse team---and when things were fixed, more often than not the fix was reverted within a week because it caused something even worse. For the first six months of our time using them, Parse would only report downtime post facto and backdated by a day. “F@#$k Parse” was perhaps the most frequently uttered phrase among all of us in our douchebag Mission district headquarters. What a life. All the time, push notifications inexplicably stopped working for hours at a time---we were running a daily sales app, and this really killed us. It ruined dozens of auctions and pissed off tons of our users. But what's even worse? Parse made my life a living hell for a year, and I'm glad they're gone.

AlwaysBCoding 11y ago
It's a good thing they had great documentation... oh wait.
derefr 11y ago
Interesting. Sounds like Parse wasn't nearly as mature as they made themselves out to be. I'd have expected at least PaaS levels of stability—by, at the very least, pinning each client to a particular API version with guaranteed semantics until they choose to shift to making requests on higher-versioned equivalents of each API resource. A thought: if "Parse" had originally just been this open source Parse Server offering, and you had taken that and plopped it on e.g. Heroku, would that have been a better deal for you? Seems like "apply FOSS to PaaS to get BaaS" wouldn't have been that much more hassle, operations-wise; and you would have been able to upgrade the backend only when you liked, rather than having it mutated out from under you.
- jonsterling 11y ago
  Thanks for your comment; regarding your thought, from my perspective there was nothing that Parse provided that was easier than just building the app on Heroku ourselves. And we wouldn't have been stuck in the horrible node/javascript ecosystem then! So, I would say, if Parse had been this Parse Server product from the start, that would have been a lot better! But there wasn't really any need for such a thing at my company. We had to use Parse for incestuous "YC alum" reasons---we did not have a technical need for it.
  - akarve 11y ago
    really "incestuous"? firebase is/was a YC company, too. it's sad when cronyism trumps reason.
    - jonsterling 11y ago
      Haha, well funny you should mention it---management were also encouraging me to look into using firebase for something too, but I put the kibosh in it because we had had so much trouble with Parse. The truth is, we had no need for any of these products (even though I have heard firebase to be way better than parse); we needed to get serious and just write a little API server + postgres database and toss it on Heroku.
BinaryIdiot 11y ago
I'm glad I'm not the only one who had parse slow down development. It was very...janky especially the REST API.
- jonsterling 11y ago
  I really felt like I was being gaslighted, being surrounded by all these YC alum douchebags who never fail to have some gushing remark about it...
zachlatta 11y ago
Ran into the exact same issue when using Parse. I was working on an app that operated primarily through push notifications. The push notification downtime was horrible -- I remember having to get on calls with clients apologizing profusely for the downtime. We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much. I never heard people talking about the difficulty of moving off of Parse, especially in mobile clients that were developed with the Parse SDK. I spent a ridiculous amount of time getting Parse synced with our custom backend so old clients wouldn't break. Final thing: debuggin. For nearly any issue, a half-assed solution---often not usable in production---by one of their staff was buried deep into their forums. Super painful.
- jonsterling 11y ago
  Exactly, exactly, exactly! > We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much. We were also hooked into the same scam! > For nearly any issue, a half-assed solution---often not usable in production---by one of their staff was buried deep into their forums. Super painful. Haha, well put. They always directed people to their pathetic "support forum", where one of their staff would propose a criminally bad "solution" to a problem, which no self-respecting engineer could even sanction putting into production.
akarve 11y ago
painful. though more an indictment of parse than BaaS. the firebases of the world seem to work better. 20/20 hindsight, when should you have gotten off of parse and why didn't it happen?
- jonsterling 11y ago
  I don't think I'm allowed go go into details based on a contract that I signed, so I will just say "we should have got off it earlier".
  - lacker 11y ago
    Hey I'm not sure what contract you're referring to, but from a Parse point of view I think you should feel free to go into details about what didn't scale for you about Parse. There is definitely a tradeoff between "ease of use" and "ease of scaling" in many places and using a "backend as a service" won't be the right thing for everyone. I would rather that people be honest and open about what works well and what doesn't.
    - jonsterling 11y ago
      Hey there—I've done my best to be as honest and up-front about my experience with Parse. (I apologize if it has seemed overly harsh; but it ate its way into many different parts of my life and really made my year difficult.) But I can't really go into much detail about what we did at our company and why we did it, because when I left, I took a severance on certain terms. And in any case, it's not really appropriate to drudge up old arguments, and I have no interest in making comments that might make it more difficult for the people I worked with to do what they want to do now.
JohnHaugeland 11y ago
can you help me understand why you didn't give up on them in the first week? i'd love to figure out how to lock people into expensive shitty projects that belong to me

AlwaysBCoding 11y ago

It's a good thing they had great documentation... oh wait.

derefr 11y ago

Interesting. Sounds like Parse wasn't nearly as mature as they made themselves out to be. I'd have expected at least PaaS levels of stability—by, at the very least, pinning each client to a particular API version with guaranteed semantics until they choose to shift to making requests on higher-versioned equivalents of each API resource. A thought: if "Parse" had originally just been this open source Parse Server offering, and you had taken that and plopped it on e.g. Heroku, would that have been a better deal for you? Seems like "apply FOSS to PaaS to get BaaS" wouldn't have been that much more hassle, operations-wise; and you would have been able to upgrade the backend only when you liked, rather than having it mutated out from under you.

jonsterling 11y ago
Thanks for your comment; regarding your thought, from my perspective there was nothing that Parse provided that was easier than just building the app on Heroku ourselves. And we wouldn't have been stuck in the horrible node/javascript ecosystem then! So, I would say, if Parse had been this Parse Server product from the start, that would have been a lot better! But there wasn't really any need for such a thing at my company. We had to use Parse for incestuous "YC alum" reasons---we did not have a technical need for it.
- akarve 11y ago
  really "incestuous"? firebase is/was a YC company, too. it's sad when cronyism trumps reason.
  - jonsterling 11y ago
    Haha, well funny you should mention it---management were also encouraging me to look into using firebase for something too, but I put the kibosh in it because we had had so much trouble with Parse. The truth is, we had no need for any of these products (even though I have heard firebase to be way better than parse); we needed to get serious and just write a little API server + postgres database and toss it on Heroku.

BinaryIdiot 11y ago

I'm glad I'm not the only one who had parse slow down development. It was very...janky especially the REST API.

jonsterling 11y ago
I really felt like I was being gaslighted, being surrounded by all these YC alum douchebags who never fail to have some gushing remark about it...

zachlatta 11y ago

Ran into the exact same issue when using Parse. I was working on an app that operated primarily through push notifications. The push notification downtime was horrible -- I remember having to get on calls with clients apologizing profusely for the downtime. We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much. I never heard people talking about the difficulty of moving off of Parse, especially in mobile clients that were developed with the Parse SDK. I spent a ridiculous amount of time getting Parse synced with our custom backend so old clients wouldn't break. Final thing: debuggin. For nearly any issue, a half-assed solution---often not usable in production---by one of their staff was buried deep into their forums. Super painful.

jonsterling 11y ago
Exactly, exactly, exactly! > We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much. We were also hooked into the same scam! > For nearly any issue, a half-assed solution---often not usable in production---by one of their staff was buried deep into their forums. Super painful. Haha, well put. They always directed people to their pathetic "support forum", where one of their staff would propose a criminally bad "solution" to a problem, which no self-respecting engineer could even sanction putting into production.

akarve 11y ago

painful. though more an indictment of parse than BaaS. the firebases of the world seem to work better. 20/20 hindsight, when should you have gotten off of parse and why didn't it happen?

jonsterling 11y ago
I don't think I'm allowed go go into details based on a contract that I signed, so I will just say "we should have got off it earlier".
- lacker 11y ago
  Hey I'm not sure what contract you're referring to, but from a Parse point of view I think you should feel free to go into details about what didn't scale for you about Parse. There is definitely a tradeoff between "ease of use" and "ease of scaling" in many places and using a "backend as a service" won't be the right thing for everyone. I would rather that people be honest and open about what works well and what doesn't.
  - jonsterling 11y ago
    Hey there—I've done my best to be as honest and up-front about my experience with Parse. (I apologize if it has seemed overly harsh; but it ate its way into many different parts of my life and really made my year difficult.) But I can't really go into much detail about what we did at our company and why we did it, because when I left, I took a severance on certain terms. And in any case, it's not really appropriate to drudge up old arguments, and I have no interest in making comments that might make it more difficult for the people I worked with to do what they want to do now.

JohnHaugeland 11y ago

can you help me understand why you didn't give up on them in the first week? i'd love to figure out how to lock people into expensive shitty projects that belong to me