Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Facebook is closing Parse

blog.parse.com

Post reply on HN
Print view View original

321–330 of 543 posts

Re: Facebook is closing Parse

#321

Post by marktangotango »

asadlionpk wrote: post #269
mayop100 wrote: post #248

Earlier quoted context omitted.

[Firebase founder here] We'd love to know what limitations you've run into and how we can do better! Send me a tweet: @startupandrew

Well I love Firebase, but to put it naively, Firebase needs more advanced queries. Even more than usual because it is running 'far' from my backend, so queries from backend are expensive. For example, if there was a way to selectively bring back children of an object etc. I know there are workarounds (and I am doing those) but since Firebase is a DBaaS it needs to account for that when compared to other DBs.

This really seems like a limitation of nosql/mongodb, would it be worthwhile to reconsider sql/nosql trade offs?

Re: Facebook is closing Parse

#322

Post by drchiu »

Definitely kudos to Parse for open sourcing what is essentially their platform.

Nonetheless, this speaks to the difficulty many of us in the startup world face when choosing our technology stacks.

Parse, Firebase, and other similar BAAS platforms are very attractive for a variety of reasons. But in the end, many of them get acquired and eventually wind down, or run out of money because it's so difficult to run profitably.

Selling to developers is oftentimes a difficult thing to do. I've seen multiple products aimed at developers that look great and get me excited, but when I sit down and really analyze it -- each of them have yet to make even a single dollar from me. I'm sure many of us are in similar positions.

Re: Facebook is closing Parse

#324

Post by mpinteractiv »

I love your product, thanks for releasing a "community server". I liked it because it contained enough business logic to get started with most projects. Built that with it among other things :

https://github.com/Mparaiso/playground ( a jsfiddle lite directly available on github , the UI is angularjs : https://mparaiso.github.io/playground )

So thanks. You were the best BaaS feature wise IMHO.

EDIT: however just one point : you took 1 year to rewrite your API in Go, which yielded performances but the product didn't evolve that much in the meantime because of the rewrite, was the experience positive or negative?

Re: Facebook is closing Parse

#325

Post by giarc »

mayop100 wrote: post #201
DocSavage wrote: post #51

And just when I was about to choose between Parse and Google's Firebase. Makes me wonder if Firebase will follow the same path through acquisition, seeming stability, followed by closing? As far as similar open-source systems, it seems like Mozilla's Kinto compares favorably to Parse after it's code is released: http://kinto.readthedocs.org/en/latest/overview.html There's a nice table there comparing the different se…

[Firebase founder here] We're not going anywhere. We have strong backing here at Google and are continuing to make big investments in our platform. You'll see big things from us soon. What makes us different? Firebase is very complementary to Google's other product offerings. Cloud for one, as well as Angular, Polymer, GCM, etc.

Old Parse user here - any plan to provide a swift SDK?

Re: Facebook is closing Parse

#326

Post by wesleyfsmith »

lacker wrote: post #64
adriancooney wrote: post #19

Wonder why they actually shut down? Seems like it was an unexpected decision. http://blog.parse.com/events/announcing-f8-2016/

The NYT article has some pretty good explanation here. http://bits.blogs.nytimes.com/2016/01/28/facebook-to-shut-do... "Facebook also would have had to invest untold millions of dollars in capital and, more importantly, engineering talent, to get the Parse business fully off the ground to have a better chance at making a dent in competitors like Amazon, Microsoft and Google." That old blog post doesn't make sense any…

Must have been really hard shutting down your baby. Do you wonder what could have happened if you hadn't sold?

Re: Facebook is closing Parse

#327

Post by BinaryIdiot »

jonsterling wrote: post #216
jshen wrote: post #195

Earlier 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'm glad I'm not the only one who had parse slow down development. It was very...janky especially the REST API.

Re: Facebook is closing Parse

#328

Post by wkoszek »

chatmasta wrote: post #133

I don't understand why Facebook never integrated Parse into its own datacenter infrastructure. As far as I can tell, Parse still hosts all of its infrastructure on EC2 (DNS lookups for every Parse service point to an EC2 IP address). Hosting on EC2 made sense when Parse was an independent company, but didn't they sell to Facebook so they could benefit from Facebook infrastructure? This seems like Facebook throwing in…

You mean main FB data-centers? The reason can be as simple as security standards used in both services may not be compatible.

Re: Facebook is closing Parse

#329

Post by asadlionpk »

marktangotango wrote: post #321
asadlionpk wrote: post #269

Earlier quoted context omitted.

Well I love Firebase, but to put it naively, Firebase needs more advanced queries. Even more than usual because it is running 'far' from my backend, so queries from backend are expensive. For example, if there was a way to selectively bring back children of an object etc. I know there are workarounds (and I am doing those) but since Firebase is a DBaaS it needs to account for that when compared to other DBs.

This really seems like a limitation of nosql/mongodb, would it be worthwhile to reconsider sql/nosql trade offs?

Well I would say reconsideration is always right but it's expensive (nosql->sql is big deal) when you are a fast-paced startup and don't want to spend resources on non-critical things. I know it will get critical someday, so we are slowly finding a solution to it.
Post reply on HN