4 ms·

"This announcement just underscores the importance of having full control over your backend" I disagree. If using something like this let's you get to market m

by jshen 11y ago

"This announcement just underscores the importance of having full control over your backend" I disagree. If using something like this let's you get to market much faster, much cheaper, and find market fit faster/cheaper, then it's worth it. Depending on the need it can take millions of dollars and year(s) of work to then begin working on the actual business objectives.

nodamage 11y ago
If you're building a nascent mobile app it probably won't take millions of dollars and year(s) of works to get up and running, regardless of what backend you use. If you do have a project that will take millions of dollars and year(s) of work to get up and running, I'm going to guess you have much bigger problems than what backend you use, and choosing something like Parse won't help you that much.
jonsterling 11y ago
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.
api 11y ago
I'd change it to "if you depend on third party services, be sure to architect things so that you could migrate if you have to."
deleted 11y ago
[deleted]
argo12 11y ago
Yes absolutely. Hasura.io is coming up with a BaaS which is also simultaneously trying to address the "full control over your backend" problem. We put up some of our thoughts here:https://news.ycombinator.com/item?id=10994104 https://news.ycombinator.com/item?id=10994104

by jshen 11y ago

nodamage 11y ago

If you're building a nascent mobile app it probably won't take millions of dollars and year(s) of works to get up and running, regardless of what backend you use. If you do have a project that will take millions of dollars and year(s) of work to get up and running, I'm going to guess you have much bigger problems than what backend you use, and choosing something like Parse won't help you that much.

jonsterling 11y ago

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.

api 11y ago

I'd change it to "if you depend on third party services, be sure to architect things so that you could migrate if you have to."

deleted 11y ago

[deleted]

argo12 11y ago

Yes absolutely. Hasura.io is coming up with a BaaS which is also simultaneously trying to address the "full control over your backend" problem. We put up some of our thoughts here:https://news.ycombinator.com/item?id=10994104 https://news.ycombinator.com/item?id=10994104