Live data from Hacker News

Facebook is closing Parse

blog.parse.com

331–340 of 543 posts

Re: Facebook is closing Parse

#331
post #319

Earlier quoted context omitted.

[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.

"We're not going anywhere." I'd like another answer like. "We are thinking about providing a community version that one can deploy on its own servers, then we provide the IaaS when the customer might want to scale". If Parse had an opersource version to begin with, it would have been much much more successful and people would have been less worried about building on a third party platform. If Firebase closes tomorrow…

> If Firebase closes tomorrow there will be no migration strategy for people who built their infrastructure around Firebase.

To be fair, the same thing could have been said about Parse yesterday. Thankfully they've done as good a job as can be expected in releasing an open source implementation.

But indeed, I might have stuck with Firebase had there been something like that available. Instead, we switched while patiently waiting for a js implementation that supported offline sync.

Any updates on the availability of that?

Re: Facebook is closing Parse

#332

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…

[Couchbase Developer Advocate] You can also look at Couchbase Mobile ( http://developer.couchbase.com/mobile ) that is an open source mobile database and provides full power of a Couchbase database locally on the device. You can create, update, delete, query, sync and much, much more. Couchbase server provides full querying capabilities using SQL-like syntax for your JSON documents.

What do you use for cloud hosting the server?

Re: Facebook is closing Parse

#333

This announcement just underscores the importance of having full control over your backend. Yes, it's more work, but if you're writing apps that seriously depend on backend services, it's simply too much risk to depend on anyone else. Fortunately in this case Facebook offered generous lead time to migrate off Parse.com, but they were not obligated to do so, and other providers might not be so generous in the future.…

A few more thoughts:

1. This effectively poisons the well for any other BaaS providers out there. If two of the biggest companies in this space (StackMob and Parse) can get acquired and shut down in less than 5 years, what does that say about the future of the smaller companies in this space? As a developer how could you possibly trust any of these companies going forward, based on this track record?

2. Syncing is notoriously difficult to get right. Building a generalized syncing solution is even harder. Bugs in sync code tend to lead to data loss, which leads to angry customers. These types of bugs are hard enough to track down and fix in your own code. Trying to track down and fix bugs in complex third-party code can be damn near impossible.

If you decide to adopt a third party solution that purports to do your syncing for you, do your research carefully. Not just by looking at the toy samples which look easy to set up and work perfectly, but experiences and reports from actual developers who have tried such solutions. What kind of problems are they having? What are the limitations of the current implementation? How mature is the product? How responsive are they to bug reports? If something goes wrong and data is lost, how much insight do you have into the system to figure out why?

Re: Facebook is closing Parse

#334
post #2

Separately, we developed an open-source Parse-compatible API server for Node/Express. https://github.com/ParsePlatform/parse-server This, along with the database migration tools released earlier, allow developers a full migration path to move from Parse hosted data + API to their own infrastructure. Over the weekend, I set up a website & app on a $5 DigitalOcean box running Parse and Mongo locally.

Alternate title: “Facebook is opening Parse”

It's actually incredible that they didn't position it that way.

Re: Facebook is closing Parse

#336
There are going to be a lot of mobile "full stack developers" that are going to have to scramble now to find another way to avoid learning how to build a simple API server and database.

I only used Parse for one small project a few years ago. At the time their scheduled tasks feature was new and I found it hilarious that there was a bug that mixed up hours and days in the scheduler. That is when the scheduled tasks actually ran at all.

Re: Facebook is closing Parse

#337
post #2

Separately, we developed an open-source Parse-compatible API server for Node/Express. https://github.com/ParsePlatform/parse-server This, along with the database migration tools released earlier, allow developers a full migration path to move from Parse hosted data + API to their own infrastructure. Over the weekend, I set up a website & app on a $5 DigitalOcean box running Parse and Mongo locally.

Kudos for opensourcing ! but :

https://news.ycombinator.com/item?id=9693743

I guess the time spent ( a year ? ) on the Go version didn't help feature wise. The product didn't evolve that much in the meantime.

I hope you provide a solution for cloud code and webhooks , webhooks at least , since cloud code is just javascript. Please be sure to host the documentation somewhere, like github pages.

Good luck for your next project. I'd love to read a "post-mortem" once the service is definitely closed.

Re: Facebook is closing Parse

#338

This announcement just underscores the importance of having full control over your backend. Yes, it's more work, but if you're writing apps that seriously depend on backend services, it's simply too much risk to depend on anyone else. Fortunately in this case Facebook offered generous lead time to migrate off Parse.com, but they were not obligated to do so, and other providers might not be so generous in the future.…

Wrong! Everything we build is on top of layers upon layers and not a single company/IT team has/can fully control all of them! So you suggest: build your own backend API and run it on a VPS/Container/whatever. Do you have full control on the hardware? The virtual machines? The vendor's infrastructure? Let's move a layer up. Do you have full control over the framework you used? The database engine? Does the sum of knowledge/experience in your team guarantees full control on all these layers? Under a security threat who provides the patches? Your team? Do you run your own mail server? Did you code our own OS?

This is rethorical of course, all the answers are no.

What exactly is wrong about trusting one more layer to 'experts'?

Not all dev teams can afford a backend ninja just as they cannot afford a network admin or a telecom engineer. Companies like Parse are on the right track, they provide a much needed service.

I've been on this trade long enough to witness the transition of companies hosting webservers in-house to realizing a dedicated server made more sense (one team of experts managing many machines), then VPS, then containers....then BAAS.

Re: Facebook is closing Parse

#339

I hate to be "that guy", but I use their analytics too, along with in-app push notifications that can be targeted to groups of users. Anyone have experience and recommendations for alternatives that are just as easy to implement in an iOS or OS X app?

I'll second MixPanel, but also Fabric.io (their crashlytics product).
Post reply on HN