Earlier quoted context omitted.
> Maybe its not such a good idea after all to code your app to a proprietary API in the cloud. That's why you write an adapter.
That's exactly what I did. I wrote a wrapper around their REST API. Feeling pretty good about that decision right about now.
Facebook is closing Parse
351–360 of 543 posts
Re: Facebook is closing Parse
#352Re: Facebook is closing Parse
#353Re: Facebook is closing Parse
#354Re: Facebook is closing Parse
#355Re: Facebook is closing Parse
#356Re: Facebook is closing Parse
#357Re: Facebook is closing Parse
#358I used Parse. But I found it's expensive if you want to use some Pro features. I built my own server on a cheap VPS later.
Re: Facebook is closing Parse
#359Remember this comment.
Re: Facebook is closing Parse
#360Earlier quoted context omitted.
"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.
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…
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.