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.
Migration is based on data size, but setting up the API server on a new VPS is quick... I'd say less than one hour from a fresh image on Digital Ocean. I'll try to publish a guide for that part.
You can also look at Couchbase Mobile that provides full power of a Couchbase database locally on the device. You can create, update, delete, query, sync and much, much more.
It'll really depend on your app, and how many features you used at Parse. In most cases, it should be easier than rewriting your entire app with Firebase, but you should carefully look through the guide and make that decision yourself.
Thank you for releasing tooling to deal with migrating as well as releasing the server itself.
Too often services don't think about the full exit / shut down strategy and as disappointing as it is to see Parse go, it's nice to see it will actually live on in a way that can't be shut down by a corporate decision.
Sorry my mistake. They have just open sourced the server not the dashboard. But some one has said they are going to open source the dashboard and all soon.
Kudos to Parse for providing an open source path forward. I know a lot of enterprise users who will only look at fully open source stacks, for a variety of reasons. It's good they are giving users a year to migrate. I expect Couchbase Mobile to see a lot of evaluations as this process plays out.
I will be watching to see how the community grows. It looks like the ExportAdapter.js module in parse-server is low hanging fruit to connect to stuff like Couchbase Sync Gateway, which would give access to a multi-vendor ecosystem including IBM and Apache.
[Full disclosure: I'm a FT Couchbase mobile developer]
Agree 100% -- Parse deserves huge kudos for that move.
Ex-Parse customers should definitely check out Couchbase Mobile, which has some functionality overlap with Parse and is already open source with several repos on github:
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.
What about push notifications and Parse Config? Social apps that triggered push notifications now loose that functionality when moving to Parse Server, right?
Also what about security? One of the beautiful things about Parse was not having to worry about servers and the security of back-end because you knew Parse was on top of it.
Depends on your viewpoint: One of the beautiful things about having your own back-end is not having to worry whether or not some 3rd party team is not neglecting security of the back-end because you know you are on top of it.
You sound like somebody who feels comfortable handling security, but for boostrapped and/or a self-funded or even small funded startups, that's extra money that goes to plug a major whole that didn't exist with Parse because they made user authentication, permissions, and security simple.
I'm no security expert. So now instead of concentrating on growing the user base, gaining traction and making the best experience possible for our users, that means finding, interviewing, and hiring more people to handle back-end security which takes a lot of time out of improving the product.
How time consuming on a hours per day would it be to stay on top of handling security on your own? How many engineers would it take and at what cost per engineer?
It really sucks Parse is closing down, it was one of the best alternatives to Firebase, indeed better for straightforward REST use cases, and I really enjoyed using it.
It's nice that you've released an open source migration path. I hope somebody else can fill the niche of a fully hosted API-as-a-service. Best wishes.
Hacker culture of Facebook makes it really valuable company in terms of engineering. Dropbox and Google (Mailbox & Reader at least) should learn something from them. Incredible move and good luck in future endeavors!
Alas, open sourcing Reader wouldn't have done much: the code's all tied heavily into Google internal infrastructure. (Full disclosure: my team pulled the plug on Reader.)
It's sad that you are shutting down but I think it's awesome that you are releasing the platform source. Who knows, this could be the birth of a great FOSS project.
Hey everyone looking for a migration path out - we have a “DevOps-as-a-Service” model where we can migrate Parse folks to AWS (not DO unfortunately) with full infrastructure automation, immutable infrastructure, autoscaling, chatOps deployments, monitoring and alerting, etc. for a flat rate. We have a platform that we’ve built that makes this possible - think of it as a Django/Rails/etc. for AWS: https://www.reactiveops.com/devops-as-a-service/
Although we have a framework, it lives in your github and runs in your AWS - there's no lock-in whatsoever. Ping me at matt [at] reactiveops dot com if you're interested!
I tried to use node on a $5 DigitalOcean dropplet a couple of times but whenever I tried to run npm to install something, it would run out of memory and be killed. Frustrated with this experience, I have stayed away from Node.
I'm a web and mobile developer. Parse it is a good solution for a quick app backend setup but I never realized build big things over there. To me the most important to me is no vendor lock-in I see as very important to have full control over what I'm developing. I started to use a great platform http://parse.back4apps.com and Im happy with the results. I recommend it as a migration option. At any moment you can have your code totally portable.
If you can't self-host because you don't have the ability to, but can't use cloud services either because they could shut down, what alternatives do remain?
I think use an open source platform which has both self-hosted and managed as options. So when managed shuts down, You can self host it. I'm the founder of CloudBoost.io - and We're an alternative to Parse. We're both on Docker (Self-hosted) and Managed at CloudBoost.io
If you see my other comment regarding this, that's exactly what I'm saying.
It may never happen—I think Oculus may be closer to their core business—but if you're building on someone else's platform, you should be prepared for the possibility that the platform could disappear should it no longer be a part of that company's strategy.
If you're building on Oculus as a platform, I applaud you, and I wish you and your product a long, healthy life. But have a Plan B.
If it's not strategy, it's charity. And most corporations are not much given to that.
I don't think that's reason enough. AWS wasn't/isn't Amazon's core business, either. For a company that wants to be deeply integrated in all web-connected software, it makes sense to make it as easy as possible for developers to work with them.
It's really hard to build trust when products disappear. Building on top of google is hard for this reason, and Facebook is beginning to look eerily similar. Recall all of the wonderful social graph access that once existed and see, now, the wake of crippled API's where they once lived.
Since it is impossible to build everything from scratch, some compromise must be made, but I wonder whether that compromise can reasonably include offerings from $BIG_CO? Certainly open-source projects implode as well, but rarely with the scale of things like Google Reader or Parse...
The acquisition happened nearly 3 years ago. To their credit, they kept running it for longer than a lot of other companies would have.
Anyone in the situation of seeing their platform provider acquired should see the writing on the wall. It's unfortunate, but it's the reality. Enjoy the continued services while [if] they last, but always have a Plan B.
>> "Anyone in the situation of seeing their platform provider acquired should see the writing on the wall."
In this case though FB seemed to embrace Parse and continued to develop it. It would have been much better to shut it down after acquisition. FB's support of it probably helped it gain more trust that it would stick around.
the parse server is just a couple K sloc, and not (from a cursory browse) exactly revolutionary. writing such a backend (which one would probably leverage over several projects) is qualitatively different than "writing your own compiler from scratch every time".
Mine was that, in the larger context that is computing, you must build on top of something because redoing everything from scratch every time would be ridiculous. You likely trust your CPU instruction set, and your bios and a million other things, but some things you can't trust. Knowing the difference is non-obvious, which is the fact I was lamenting.
> Building on top of google is hard for this reason, and Facebook is beginning to look eerily similar.
The danger is using something closed-source and proprietary. Most of the popular products/services released by Google and Facebook are open-source, at least.
Even in this case, Parse provided open-source tools that will keep legacy code running with minimal changes. I think it's about the best-case scenario you could ask for when a closed-source platform is shut down.
I just started developing something in parse in the last 2 months, i really really liked the platform, this totally sucks. Does anyone have any recommendations for alternatives with similar features?
Former employee of Kinvey here. But I absolutely loved working there and they have an incredibly formidable offering which I personally feel surpassed Parse.
If you’ve been using Parse as part of a photo-sharing app, you might want to take a look at http://www.ostetso.com. While we’re by no means a drop-in replacement for Parse, what we DO offer are all the pieces needed to create an instagram-like app, including the image hosting, user management, code that gives you a gallery of user images, etc., etc. (iOS only at this point though.) Check out the source code for an example app on Github (at https://github.com/PrecipiceLabs/Ostetso_SharePictures) that uses the Ostetso platform.
"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 more - we should just take it down.
I do wonder, but it's just impossible to know. Working on a startup, there are just so many variables out of your control or understanding. You can't predict what will happen. You can only aim at a vision and do your best to get there.
While I'm sure this sucks for a lot of people, I'll be honest the shutdown seems pretty fair. One year notice, detailed migration path with accompanying migration tools, and an open source release of the product itself.
I didn't use parse, but this seems like a reasonable way to do it.
It's really important as people build apps (and business value) through composition of smaller services rather than composition of code that they become aware of these external dependencies. And not just at build time, but during the operation of these apps/business processes.
also major props for being up-front about the fact that they're shutting down the service and they realise it sucks for their users, rather than some "incredibly journey" style bs.
Is it an open source release of the core Parse product? I am genuinely curious, hence the question.Correct me if I am wrong, but this means that most of their product is the Parse server and whatever migration tools they used to store data for users.
Deals often are on and then off or otherwise not necessarily expected to happen. In the midst of that, services typically and properly tend to push forward with what they were already doing as though no deal is going to happen. The worst thing you can do, is halt your progress during a negotiation.
Halting progress indeed seems like the commonsensical thing to do. A massive UI overhaul is not be the most resource-efficient course of action if you plan on announcing your demise. Hence my startling
It actually makes sense that they would cancel the project after a major release (which they were already working on), especially since they open-sourced the stack.
I have no knowledge of what happened at Parse but based on other experiences I've had, a "sudden" shutdown could be a sign of things being done correctly.
Too often, products are in an extended state of limbo. Internally, the company has given up on it but has been dragging its feet on making the decision to shut it down (or just slow about making the decision public).
As a user, I like to know ASAP if a product I use is probably being killed.
From the company's perspective, keeping a product around half-assedly will probably lead to a slow death anyway; just kill it quickly.
It will be funny to see all of the abandoned apps that start failing a year from now. Obscure games, utilities, etc. Most people won't be bothered to go through the stress of an App Store review process to update an old free-to-play app that's not even making them revenue. But how many people's morning commutes will be ruined when their old games or news apps fall apart? The price of progress (and of liquidity), I suppose...
Kinda. I mean, I can dust off my old console and play the games on that any time I want. App Store stuff means built in expiration date. Cloud integration means built in expiration date. Price of progress.
Your old console ran the same code for years on end with no updates and no new features. Your phone's updating all the time. Thus, software TTL is much lower. (Software TTL for your console is determined by how long your cartridge serves up good data.)
To be fair, those exact same abandoned apps would just as easily stop working because their developer didn't upkeep their custom backend - or worse, those abandoned backends could fall behind on security updates and get hacked.
Too bad. I admire them for giving people a year and giving some helpful tools. I'm glad Parse's winding down is less painful than "We're gone in 1 month, good luck, bye!".
Another data point for the "Is PaaS dead?" conversation.
Why? React and React Native are both pretty core to Facebook's main applications these days (all of Instagram is written in React, there's a smattering of components all over the main Facebook page, and multiple Facebook-written applications are written in React Native, including parts of the main Facebook app). In contrast, Parse was more of a dev-infrastructure product that didn't end up impacting developer relations as much as Facebook wanted it to (I'm guessing)
The major difference though is that react is a self-hosted open source library. Yes, Facebook could drop support for it, but there are enough people using it now that it would probably see community updates for quite a while.
The thing is it was not just 30 minutes. Between the built-in push notifications, admin console, great geo support, and easy scaling it was a complete godsend for building MVPs in a reasonable amount of time. It will be missed by many, many independent developers & consultants.
It always sucks when things have to come to an end, however, this is a pretty graceful shutdown if you ask me. Many other service providers, especially in other industries, would often times send you a letter with a month, sometimes less, notice.
From a business learning experience, I'm really interested in the reasoning. I'm hoping a detailed blog post comes out of this, which I'm sure it will, just as a "case study" of sorts.
Consider moving to Couchbase Mobile (http://developer.couchbase.com/mobile). Why?
- Its an open source solution that allows you to build mobile applications that work online and offline.
- With Couchbase Lite, you have the full power of a Couchbase database locally on the device. You can create, update, delete, query, sync and much, much more.
- Couchbase Sync Gateway gives you everything you need to securely sync on-device Couchbase Lite with Couchbase Server in the cloud.
-- Replication
-- Authentication
-- Access Control
-- Data Routing
- Couchbase Server is a high performance, scalable, always-on NoSQL database in the cloud. Sub-millisecond, high-throughput reads and writes give you consistent high performance. Couchbase Server is easy to scale out, and supports topology changes with no downtime.
Too many spam posts from you about Couchbase Mobile. Anyway I do not see the similarity. Parse is hosted platform, build for mobile developers that do not want to self-host the backends, with affordable entry cost. Couchbase Mobile is a product offering with licensing and paid subscriptions for support, pricing has to be requested in order to know the exact, and the backends (Couchbase Sync Gateway and Couchbase Server) starts few thousands dollars per node. And we have to deploy and host the backends (whether we choose to buy or use the free community version). One can choose IBM Cloudant to host, but then Cloudant is hosting CouchDB compatible database and you'd miss the Couchbase Sync Gateway component, which is the main selling points (sync, offline) of Couchbase Mobile. Correct me if wrong.
i used to be scared using app engine, but this was for start ups that really couldn't afford using anything else. They gained so much time and saved so much money, it was worth the risk.
But firebase ?? Unless you need real-time capabilities at the DB level, i really don't see the point.
Google is 100% behind us, and we're continuing to make big investments in the platform. If you have concerns, feel free to ask me questions on twitter: twitter.com/startupandrew
I wonder if Firebase will be next? They were acquired by Google in 2014. However they also acquired Divshot to join the Firebase team in 2015 which indicates they at least intended to continue with it then. Firebase does at least make more sense as part of Google's cloud services division rather than at Facebook.
The news i have heard from various googlers is, `GOOG acquired Firebase because a project started using Firebase as backend and grew very fast and they didn't want to migrate and just acquired FireBase`.
One group of developers this is going to affect most are those who used Parse's GCM Server Key for push notifications.
Since Parse is probably not going to reveal this key, Android developers using Parse for push will not be able to use their existing GCM push tokens with other services.
Parse authenticates with GCM using the API key that you provide, as do all other services AFAIK. So, all developers need to do is use that same key in their new push provider, and their push tokens will work.
The tricky part is actually making sure that all of your push tokens that are in the Parse database are migrated to the push provider that you've chosen.
EDIT: I stand corrected, looks like you have the option to use their key as you said, my apologies! Should have figured the founder of OneSignal would know ;-)
And here I was thinking that because Parse was acquired by facebook using their Push notifications offering was as safe bet as I could make. Can anyone recommend an alternative short of implementing my own GCM server app?
>We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere.
I read this as "our Facebook overlords have decided that our revenue/head can be dramatically increased if redeployed on a different part of the overall company, so they have decided to shut Parse down and move us elsewhere."
Which is a perfectly fair business decision but this is really sad to see since I saw the Parse acquisition as a beacon for platform companies being able to run independently post acquisition. :(
If resource is the question, then I wonder how come they are sustaining WhatsApp? Its a zero-profit activity, the users chat amongst themselves, what does FB gain from that? I guess the parse resource traffic would be little compared to terabytes flowing through the WhatsApp every day.
You don't have to. Majority of internet websites includes either ads or forums/comment sections coming back to FB cookies. So yes they do know what to show you on drudgereport when you chat on whatsapp. try yourself!
WhatsApp is a competitor of Facebook. It's a way to discuss with people you know in real-life, share pictures, discuss, communicate.
Many engineers see a "chat app" and a "social network" and they don't see how they can be competitors, but they really are: they compete on being the transport of communication with your friends.
Long-running WhatsApp groups with your family or a specific group of friends is completing exactly what Facebook doesn't successfully provide and what Google+ tried to: a way for a more private discussion within different social circles. And on top of that, there are many people who resist Facebook for "privacy" and happily use WhatsApp (which is very very ironic, if you think of it).
The acquisition of WhatsApp (and Instagram) has been one of the smartest moves from the Facebook management. And not only that, they even handled it correctly afterwards, by not merging one into the other, resisting the usual technical urge for refactoring, unification, removal of duplicates.
Now they basically own all the most successful communication platforms. They own the primary way most people use to communicate with the world.
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 services' features.
Can someone tell me why this was downvoted? I couldn't find anything wrong with cloudboost.io except for the absence of a Dockerfile in their dockerhub repo.
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.
I love me some Firebase, but I don't trust Google for a second. They kill projects off all the time, with no regard to the communities built around them.
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 there will be no migration strategy for people who built their infrastructure around Firebase.
> Firebase is very complementary to Google's other product offerings
Google is a big org. Tomorrow some upper executive you don't even know might decide your product doesn't add value anymore. You know that.
> 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.
1. This is pretty irrelevant to whether the mechanism is that some magical bigwig exec decides a project "doesn't add value", which is what was suggested might happen.
2. Plenty of companies kill plenty of products.
They just don't bother to announce it, they let it die quietly and silently
From a customer's perspective, Parse is not remotely related to Facebook's core products. But Firebase is part of Google Cloud Platform. So I guess as long as Google Cloud Platform is active, Firebase will be operational too.
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.
542 comments
[ 3.1 ms ] story [ 318 ms ] threadThis, 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.
Huge kudos to Facebook for providing this for Parse users.
Thanks and best; C
It'll really depend on your app, and how many features you used at Parse. In most cases, it should be easier than rewriting your entire app with Firebase, but you should carefully look through the guide and make that decision yourself.
Too often services don't think about the full exit / shut down strategy and as disappointing as it is to see Parse go, it's nice to see it will actually live on in a way that can't be shut down by a corporate decision.
http://blog.parse.com/announcements/introducing-parse-server...
I will be watching to see how the community grows. It looks like the ExportAdapter.js module in parse-server is low hanging fruit to connect to stuff like Couchbase Sync Gateway, which would give access to a multi-vendor ecosystem including IBM and Apache.
Agree 100% -- Parse deserves huge kudos for that move.
Ex-Parse customers should definitely check out Couchbase Mobile, which has some functionality overlap with Parse and is already open source with several repos on github:
https://github.com/couchbase/sync_gateway https://github.com/couchbase/couchbase-lite-ios https://github.com/couchbase/couchbase-lite-android
At least you won't have to worry about getting "Parsed".
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.
Also what about security? One of the beautiful things about Parse was not having to worry about servers and the security of back-end because you knew Parse was on top of it.
I'm no security expert. So now instead of concentrating on growing the user base, gaining traction and making the best experience possible for our users, that means finding, interviewing, and hiring more people to handle back-end security which takes a lot of time out of improving the product.
How time consuming on a hours per day would it be to stay on top of handling security on your own? How many engineers would it take and at what cost per engineer?
It's nice that you've released an open source migration path. I hope somebody else can fill the niche of a fully hosted API-as-a-service. Best wishes.
Google App Engine initial release: April 7, 2008
https://en.wikipedia.org/wiki/Google_Reader
https://en.wikipedia.org/wiki/Google_App_Engine
But yes I can see that as joining a Blogger page in the Members widget automatically subscribed you in Reader.
2k Github starts in 15h and growing...
Although we have a framework, it lives in your github and runs in your AWS - there's no lock-in whatsoever. Ping me at matt [at] reactiveops dot com if you're interested!
But of course people will keep doing it, and keep complaining when the inevitable happens.
https://xkcd.com/743/
I see you are unfamiliar with Oracle v. Google.
Sutton looked a little surprised, as if he had been asked “Why does a smoker light a cigarette?”
“I rob banks because that’s where the money is,” he said, obviously meaning “in the most compact form.”'
Why do you develop against a proprietary API? Because that's where the users are.
That's why you write an adapter.
I built a service on top of Parse and Yahoo Pipes. And I JUST finished porting the Pipe stuff to Lambda..
Oh well, nice of them to provide a DB migration tool and an open source server.
It may never happen—I think Oculus may be closer to their core business—but if you're building on someone else's platform, you should be prepared for the possibility that the platform could disappear should it no longer be a part of that company's strategy.
If you're building on Oculus as a platform, I applaud you, and I wish you and your product a long, healthy life. But have a Plan B.
If it's not strategy, it's charity. And most corporations are not much given to that.
Since it is impossible to build everything from scratch, some compromise must be made, but I wonder whether that compromise can reasonably include offerings from $BIG_CO? Certainly open-source projects implode as well, but rarely with the scale of things like Google Reader or Parse...
Anyone in the situation of seeing their platform provider acquired should see the writing on the wall. It's unfortunate, but it's the reality. Enjoy the continued services while [if] they last, but always have a Plan B.
In this case though FB seemed to embrace Parse and continued to develop it. It would have been much better to shut it down after acquisition. FB's support of it probably helped it gain more trust that it would stick around.
https://en.wikiquote.org/wiki/Mark_Zuckerberg
Impossible how? If anything, web/api dev has become way easier than it was 10 years ago.
Edit: it is turtles all the way down (and the only way it's not impossible is by virtue of standing on the shoulders of giants).
Mine was that, in the larger context that is computing, you must build on top of something because redoing everything from scratch every time would be ridiculous. You likely trust your CPU instruction set, and your bios and a million other things, but some things you can't trust. Knowing the difference is non-obvious, which is the fact I was lamenting.
The danger is using something closed-source and proprietary. Most of the popular products/services released by Google and Facebook are open-source, at least.
Even in this case, Parse provided open-source tools that will keep legacy code running with minimal changes. I think it's about the best-case scenario you could ask for when a closed-source platform is shut down.
FYI, here's the announcement of the acquisition from April 25, 2013: http://blog.parse.com/announcements/the-future-of-parse/
Relevant bits:
Q: Will my Parse app be affected in any way? No.
Q: Will Parse apps have to use Facebook functionality? No.
Q: Will Parse honor my contract? Yes, of course.
The lifespan of "cloud" services is not long. It seems to be less than five years.
https://github.com/Kinto/kinto
If you’ve been using Parse as part of a photo-sharing app, you might want to take a look at http://www.ostetso.com. While we’re by no means a drop-in replacement for Parse, what we DO offer are all the pieces needed to create an instagram-like app, including the image hosting, user management, code that gives you a gallery of user images, etc., etc. (iOS only at this point though.) Check out the source code for an example app on Github (at https://github.com/PrecipiceLabs/Ostetso_SharePictures) that uses the Ostetso platform.
Free until you get to a LOT of traffic/users.
http://blog.parse.com/events/announcing-f8-2016/
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 more - we should just take it down.
http://web.archive.org/web/20160111030708/http://blog.parse....
I didn't use parse, but this seems like a reasonable way to do it.
If you make apps and use any sort of {P,B,S,I,}aaS, do you yourself a favor and follow/subscribe/whatever to their news/release channels.
http://geekestateblog.com/monitoring-microvendors/
It's really important as people build apps (and business value) through composition of smaller services rather than composition of code that they become aware of these external dependencies. And not just at build time, but during the operation of these apps/business processes.
> We have a difficult announcement to make.
Yes, you can see their sheepishiness in the announcement.
I'm sure it was a tough decision.
That makes this decision seem very sudden.
What the hell is going on?
https://en.wikipedia.org/wiki/Apple_Inc._litigation#Libel_di...
Too often, products are in an extended state of limbo. Internally, the company has given up on it but has been dragging its feet on making the decision to shut it down (or just slow about making the decision public).
As a user, I like to know ASAP if a product I use is probably being killed.
From the company's perspective, keeping a product around half-assedly will probably lead to a slow death anyway; just kill it quickly.
The "price of progress" is suddenly not being able to play WhackAMole 3000 on your mobile phone on your way to work?
Another data point for the "Is PaaS dead?" conversation.
http://blog.fortrabbit.com/cloudscapes-rerevisited
I believe Facebook does use React for facebook.com, but not React Native for anything in production yet.
They're also putting a lot of resources on it and hiring some smart people (Dan Abramov).
From a business learning experience, I'm really interested in the reasoning. I'm hoping a detailed blog post comes out of this, which I'm sure it will, just as a "case study" of sorts.
- With Couchbase Lite, you have the full power of a Couchbase database locally on the device. You can create, update, delete, query, sync and much, much more.
- Couchbase Sync Gateway gives you everything you need to securely sync on-device Couchbase Lite with Couchbase Server in the cloud.
-- Replication -- Authentication -- Access Control -- Data Routing
- Couchbase Server is a high performance, scalable, always-on NoSQL database in the cloud. Sub-millisecond, high-throughput reads and writes give you consistent high performance. Couchbase Server is easy to scale out, and supports topology changes with no downtime.
But firebase ?? Unless you need real-time capabilities at the DB level, i really don't see the point.
Google is 100% behind us, and we're continuing to make big investments in the platform. If you have concerns, feel free to ask me questions on twitter: twitter.com/startupandrew
If anything Google is probably THE most aggressive company in discontinuing products: https://en.wikipedia.org/wiki/List_of_Google_products#Discon...
Disclaimer: I work on Google Cloud but not Firebase.
Since Parse is probably not going to reveal this key, Android developers using Parse for push will not be able to use their existing GCM push tokens with other services.
The tricky part is actually making sure that all of your push tokens that are in the Parse database are migrated to the push provider that you've chosen.
EDIT: I stand corrected, looks like you have the option to use their key as you said, my apologies! Should have figured the founder of OneSignal would know ;-)
https://parse.com/docs/android/guide#push-notifications-sett...
This requires a new release of your app, but that is a necessity in any case.
I read this as "our Facebook overlords have decided that our revenue/head can be dramatically increased if redeployed on a different part of the overall company, so they have decided to shut Parse down and move us elsewhere."
Which is a perfectly fair business decision but this is really sad to see since I saw the Parse acquisition as a beacon for platform companies being able to run independently post acquisition. :(
Actually you're working for Facebook... and you do it for free!
- hey rms, how you been?
- good Alice, just been busy - we're finally looking to buy our first house.. so excited about it can't wait!
- awesome, man! do you have location on your mind??
- well, me and wife are looking into Los Angeles and neighborhood, unsure yet..
- cool I come visit you!
- yeah you guys swing buy! We want to buy at least 4bd house, so there will be plenty of room for you to stay...
- okay see ya!
Meanwhile 2 days later on your Facebook feed:
Local Los Angeles realtor giving best tips for first time buyers...
If you buying in Cali you will be in shock about this one rule...
Learn about magic device this 60 year old used to built his own house in California.
California realtors are scary of this one website with top notch listings...
If you buying in Los Angeles you are overpaying not knowing about this law...
President Obama wants you to use first time buyers loan - click your State from the list below...
And so on...
I always thought the plan was to move Parse infrastructure onto Facebook servers...
Parse was already monetizing and they could see the margins they were getting, and were not satisfied.
Many engineers see a "chat app" and a "social network" and they don't see how they can be competitors, but they really are: they compete on being the transport of communication with your friends.
Long-running WhatsApp groups with your family or a specific group of friends is completing exactly what Facebook doesn't successfully provide and what Google+ tried to: a way for a more private discussion within different social circles. And on top of that, there are many people who resist Facebook for "privacy" and happily use WhatsApp (which is very very ironic, if you think of it).
The acquisition of WhatsApp (and Instagram) has been one of the smartest moves from the Facebook management. And not only that, they even handled it correctly afterwards, by not merging one into the other, resisting the usual technical urge for refactoring, unification, removal of duplicates.
Now they basically own all the most successful communication platforms. They own the primary way most people use to communicate with the world.
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 services' features.
I'm one of the Ramses devs http://ramses.tech and we've been working on related problems from an "executable spec" angle.
Seems backend automation is about abstracting storage/syncing and also about making development fast and accessible to different skill levels.
[edit] Oh, because of spamming. Nevermind.
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.
I love me some Firebase, but I don't trust Google for a second. They kill projects off all the time, with no regard to the communities built around them.
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 there will be no migration strategy for people who built their infrastructure around Firebase.
> Firebase is very complementary to Google's other product offerings
Google is a big org. Tomorrow some upper executive you don't even know might decide your product doesn't add value anymore. You know that.
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?
This demonstrates a pretty strong misunderstanding of how google actually works.
2. Plenty of companies kill plenty of products. They just don't bother to announce it, they let it die quietly and silently
> You could just use Parse. We're not going anywhere.
(https://news.ycombinator.com/item?id=7221823)
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.