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 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:
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.
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.)
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 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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
Developers who depended on Parse now have an interesting decision to make: export their data into MongoDB and start running their own servers, or look for an alternative BaaS provider to do it for them (which carries the same risk of that provider shutting down in the future).
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?
This will definitely make me more wary in the future. I considered both Parse and Firebase for my app's backend and even did some early prototypes using each. Parse ended up being closest to what I needed for the basic app features. I would have used Firebase for real time syncing in a multiplayer version but decided to put multiplayer on hold so I could actually just deploy something.
I kind of got lucky dodging the Parse bullet -- it was only because I quickly saw in my Parse-based prototype I was going to go over the ~1M interactions per month allowed by the free tier. At the time, the tier I could tell I'd be headed for ratcheted up to something like $100/month. I decided I'd rather just build it myself. Obviously, I'm glad I did now. Mostly because I'm on to some other things now and would hate to have to be rebuilding at this point just to keep my humble (yet very much alive and being used) app running.
On the other hand, Google seems to be doubling down on Firebase. I guess the difference is that Google (cloud division) is an infrastructure provider, whereas Facebook is a fundamentally a consumer product.
Au contraire: it opens a wider deeper well. Parse customers are now up for grabs. Do you think they will go back to program back-ends and rent a server? I personally won't.
So the supermaket chain where you usually shop at closes its stores for whatever reason. Do you go back to farming your backyard or do you find a new store?
The BAAS industry is super young, only hipsters are into it. But it makes sense so it will eventually mature. Bugs will be fixed.
Switching supermarkets is much, much, easier than switching backends. I'm sure lot more BaaS companies will pop up to grab former Parse customers. I'm not sure how many of those will still be around in another 5 years.
I strongly suspect there's something negative about the economics of BaaS services that's being implied by the fact that two of the most successful providers have shut down after acquisition.
Amazon has fully embraced BaaS. And I don't know of any AWS services they've added and then removed. I think Amazon will be the winner here. MSFT is also starting to embrace BaaS. Of course they have a less stellar history of support.
> Of course they [MSFT] have a less stellar history of support.
Microsoft supported products:
Azure - six years, .Net & Active Directory - thirteen years, SQL Server - seventeen years, Visual Studio - nineteen years, and Excel - twenty nine years.
That's exactly our thought (hasura.io) while we prepare for our "launch" next week. We've been studying Parse's growth and are definitely going after their market. Our core philosophy with the BaaS is however to keep it as open as possible. We wrote this up in response to Parse shutting down: https://news.ycombinator.com/item?id=10994104
Yes! We have over 20 apps build on in during our alpha phase - ranging from e-commerce to payment wallets. Let us know if you'd be interested to try out the beta version releasing next week. You can write to us at build@hasura.io or @HasuraHQ.
What if everything was built around streams that multiple people could read and write to and each stream would have a server that would be the authority on which operation done in which order?
I think that's a more flexible system that can include sync, but also other things.
That's what I've spent years building, and I'm hoping to make it also a completely distributed solution that works across domains:
Had a look at the link and struggling to understand the concept of streams.
A primary benefit of sync is store-and-forward, i.e. I could be offline, change a customer record, and when I reconnect it syncs to those who need it via a server.
In the streams model, how does the server know which stream messages to send to a client that's been offline for a week, if not via sync?
Also, messages. Does a message equate to, say, a customer record? I read that a message is a record of an event that happened to something?
> 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?
Especially given the fact that the very goal of most VC companies is acquisition.
I would argue that this precisely is the reason for that many shut downs after acquisition. They don't make their business to be sustainable, rarely profitable even.
"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 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.
Ran into the exact same issue when using Parse. I was working on an app that
operated primarily through push notifications. The push notification downtime
was horrible -- I remember having to get on calls with clients apologizing
profusely for the downtime. We were also paying Parse an absurd amount of money
for extra reliability, which didn't seem to help much.
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.
> We were also paying Parse an absurd amount of money for extra reliability, which didn't seem to help much.
We were also hooked into the same scam!
> 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.
Haha, well put. They always directed people to their pathetic "support forum", where one of their staff would propose a criminally bad "solution" to a problem, which no self-respecting engineer could even sanction putting into production.
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.
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.
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.
painful. though more an indictment of parse than BaaS. the firebases of the world seem to work better. 20/20 hindsight, when should you have gotten off of parse and why didn't it happen?
Hey I'm not sure what contract you're referring to, but from a Parse point of view I think you should feel free to go into details about what didn't scale for you about Parse. There is definitely a tradeoff between "ease of use" and "ease of scaling" in many places and using a "backend as a service" won't be the right thing for everyone. I would rather that people be honest and open about what works well and what doesn't.
Hey there—I've done my best to be as honest and up-front about my experience with Parse. (I apologize if it has seemed overly harsh; but it ate its way into many different parts of my life and really made my year difficult.)
But I can't really go into much detail about what we did at our company and why we did it, because when I left, I took a severance on certain terms. And in any case, it's not really appropriate to drudge up old arguments, and I have no interest in making comments that might make it more difficult for the people I worked with to do what they want to do now.
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.
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
[Couchbase Lite architect here, so I have skin in this game]
Even better, if you're using an open protocol, you can work with _either_ a hosted back-end or one you own, and move between them pretty easily. HTTP being a good example of course.
The problem is that open protocols for general purpose data sync are pretty thin on the ground. Couchbase built our sync architecture on top of CouchDB's replication protocol, which was badly documented at the time but at least open.
Couchbase Mobile (http://couchbase.com/mobile) uses this open protocol, so you can either BYO server (our own Couchbase Sync Gateway, or CouchDB) or use a hosted one like Cloudant. And you've got full access to the code (ours is all Apache licensed.)
I can't say we're directly compatible with Parse, or trivial to migrate to (the data models and APIs are different), and I'm obviously biased, but I do think it's a good alternative to jump ship to.
100% agree. Building my first notification-based app right now and Parse seemed like the obvious and best choice. Thing is, after a bit of thinking something felt...off. Not with the service, but off with the idea of attaching this small little project to something so...out of my control.
I dug around the net and found a working solution I could install on my own server, and now that's exactly what I've got: The experience of doing this on my own, the flexibility to grow as needed, and the code to implement again and again without needing anyone or anything else.
Building apps these days is a massive gamble for small guys like me. We often spend dozens of hours with little to no possibility of return.
Any action I can take that reduces stress points and increase my knowledge base, (and this would have been a massive stress point) I'll take.
Absolutely! Please do keep in mind no system is perfect, 100% reliability is a dream we all strive to attain, and even with Parse, I've read several reports on this very thread of instances of less than perfect reliability, iffy technical support, and so on. Anecdotal sure, but still.
That said: the app sends basic notifications when in-app, user-initiated events of interest occur.
I modified and use the code in the simplest possible way:
I created the API layer using my wonderful form builder software (https://www.rackforms.com). Yup, it's form software flexible enough to write endpoints. Check it out : )
The app sends simple GET requests to my server, which are in turn handled by the API job. If a notification is required, the API INSERT's a record into a MySQL table called push_queue.
The magic, I suppose, happens with a constantly running PHP script called push.php. This guy's monitored by a simple cron job that checks for its running status every minute. if it's down, cron automatically restarts the script. The notifications are not time-sensitive that 1 minute delays are a deal breaker, and of course any sent during that time are handled automatically when the script restarts.
APN Feedback is handled by a second one-the-hour cron job, which calls a simple script called feedback.php. A touch of code was added to deal with the core user's device token being removed for "followers" of that user.
Three Key Takeaways:
1. The entire server setup part took me about 5 hours, API code (which we'd need to write regardless) not withstanding. The biggest hurdle was the cron stuff, I shall never forget cron -v cron! Using a third-party service would have been almost the same time, I'd imagine. The best part is future projects will literally be counted in the minutes for start to finish notification server duties.
2. I got to use a language I adore (PHP), and learned a bunch with others I was quite new too (shell scripting, cron, etc).
3. Finally: No app is guaranteed success. I know many of these services have/had! generous free tiers, but after my first app (http://www.skipcast.net) and its frankly lousy performance, fool me once indeed.
If, by some miracle, this new app gains traction, sure, I'll consider a third party. Until then, I'll do it my self thank you very much.
In all -- a wonderful experience that I'm keen to tweak and learn more from at deployment time.
Thanks! I'm going to need push notifications for an Android app and was thinking about using Parse. This news came as a little shock, but perfect timing!
Not to be a dick, but some companies seem to care more than others about the developers that rely on their frameworks. Google doesnt seem to care much. Facebook seems to care more. But Microsoft seems to care most. They have not abandoned legacy mfc, visual basic, and win 32 developers even though they probably should have. Granted those are not services but they require maintenance resources nontheless.
Eh? I have apps that are almost 10yo on Google App Engine. Even when they forced a complete migration from the Master/Slave datastore to the High Replication Datastore, it was a pushbutton process that required minimal intervention. Honestly if I have any complaint it's that they don't force change faster.
On the other hand, Facebook's API changes at a pretty rapid pace and there are few apps older than a couple years that have survived without significant code changes. I've seen API changes that are basically "rewrite your whole app".
No, it just underscores the importance of properly architecting your apps so that they don't directly depend on Parse or others. Keeping that stuff to the periphery of your app will make it much easier to replace when the service either shuts down or you outgrow it.
Eh, regardless of how well your application is architected, it's going to be a pain in the ass to migrate if you have a lot of data/users/versions of your app out in the wild.
If you continue to rely on BaaS providers you run the risk of playing perpetual musical chairs as each one shuts down over time. That's not an acceptable level of risk for me, but, to each his own I guess.
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.
Your reductio ad absurdum is not particularly convincing. I draw the line at exactly the BaaS layer specifically because of the high risk of these providers pulling the rug out from under you.
If you disagree, fair enough, but I feel pretty bad right now for the poor developer who decided to adopt StackMob, then migrated over to Parse when StackMob shut down, and now has to migrate once again. Fool me once...
You'll move that line eventually. Datacenters were a hard problem to solve a decade ago. Now its (almost) trivial. Virtual clouds were a buzzword less than two years ago. Now they are huge and successful businesses. Same path for BAAS.
It's a different level of abstraction. They provide me with computers not data hosting. Theoretically they can have access to the software and the data on those computers but in practice they don't touch that and everything is completely in my control.
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.
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.
Schema design allows you to grab stuff you want joined all at the same time (aka the data lives together in a document) in mongodb's model. This obviously has limitations in many to many relationships where the access pattern isn't clear, but often these tradeoffs can work.
Would you like to try out our alternative approach instead at Hasura.io? Parse like API on Postgres - with all SQL queries possible! We'd love to chat if you are still evaluating options @HasuraHQ. We are launching our public beta next week. Here is a short post of our take on the Parse shutdown: https://news.ycombinator.com/item?id=10994104
for most applications i hypothesize that the cost of writing and maintaining your own backend will far outstrip the cost of the occasional migration.
if anything, the pressure is towards frontend:backend isolation, not away from BaaS. (in the spirit of segment.io for analytics.)
one ironic signal here is that money is bad for survivorship. facebook killed parse because it doesn't move the needle for facebook, but parse might have been a fine & profitable standalone business.
Developers will now be skeptical about using any BaaS. It can be acquired and shut down. They have every reason to be. We built a BaaS too. It is however built around this core philosophy of developers having complete control over their app backends. Here is the post we wrote about this: https://news.ycombinator.com/item?id=10994104
It doesn't matter how tightly coupled your codebase is. If you have a client app that talks directly to Parse.com, it will stop working a year from now, and you will have orphaned users. Even if you release a new build that points to a new backend, not everyone regularly upgrades, not everyone can upgrade.
Yes, self-hosting falls under "owning your own backend". The managed option carries the same risk of shutdown as with any other provider. I think you can stop spamming your website in this thread now that you've mentioned it a half dozen times though.
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.
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.
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.
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'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.
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
> 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.
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.
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.
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.
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.
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.
1/ parse wasn't a core service for facebook, nor a relevant source of a revenu AND their API wasn't standard. Those points combined made it very risky for people to use it.
2/ since they open sourced their API now, and the service was a paid service, there's a very high probability that someone will very soon create a 100% compatible PAAS.
3/ firebase will be next to shutdown. Not because they suck, but simply because they're exactly in the same case (proprietary,non standard, critical technology, held by a company who don't really care about it for its money service). People won't sign up on firebase anymore, so they will have to shut down quite soon.
4/ Every non core project run by facebook should be looked upon with extra caution now. Yes, that includes occulus. They're clearly not going to sell many devices, and gaming console maker (aka Sony) will have the lion's share of the gaming market. So, expect fb to shut it down in 2 or 3 years if it doesn't get a very large marketshare (the only use case large enough i can think of that is not gaming being porn).
5/ I personnaly would be really hesitant now to run on something like google app engine. I wouldn't be surprised to see google and microsoft moving forward api standardization for core cloud services on a much faster pace. Except amazon, nobody is really safe now.
I think you're pretty far off the mark when you say that Oculus is at risk if they don't sell enough devices.
Of course, we have to go off of what Oculus and FB says, but they are working to create an ecosystem and market for VR experiences and seem to be pushing VR forward wherever they can; look at Oculus Studio and the work they're doing to create interactive movies, as well as the software deals with partners like Samsung's Gear VR. Plus, VR is one of the three stated future pillars of FB (the other two are AI and Internet-for-all).
I'd be willing to put money on Oculus being around and still being a viable business for FB in three years, even if the Oculus Rift hardware is not a commercial success. If the hardware is not popular, they will still be pushing VR forward in other ways. VR is a huge opportunity and is likely to be the entertainment medium of the future. I sincerely doubt FB is going to be overreacting and shutting down Oculus the way you describe.
Or maybe it will turn out that VR is just a niche market or passing fad (for the Nth time). Or it won't gain the required traction within the FB executive's patience threshold. Both are very likely outcomes.
> VR is a huge opportunity and is likely to be the entertainment medium of the future
They probably have a lot of patent, and i agree that VR is not going away. I was talking about occulus as a fb branded hardware and development platform.
To be fair, would they say anything else? Even if Google had plans of shutting them down in 3 months, it's not like they'd come out and say, "Oh, we'll be joining parse next quarter."
I agree that Firbase is a ool option and probably safe as they recently took steps to lock it into the google account. Someone will inevitably say google kills projects often, but they probably won't kill this.
Alphabet's strategy seems to be yo onboard new developers and get into mobile.Firebase is a good way to begin that pipeline allowing new devs into googles ecosystem and controlling how tags work on websites by creating their own library and pushing people in.
Why did parse fail though? Seems like a good strategy for Facebook.
> google and microsoft moving forward api standardization
Google maybe.
Microsoft never - if it's one thing that is in their DNA than it's they always have undocumented API edge cases, so they can change them right in front of a competitor - they have a very long history doing that. Ask Apple (Word, IE, etc), DOS-competitors (DR-DOS, etc), IBM (OS/2, DOS, OpenOffice, Lotus, etc), "open" Office format (docx, xlsx, pptx = weird XML serialization of their old binary OLE2 based Office format), Win16API, Win32API, NTkernel API, and many more.
> gaming console maker (aka Sony) will have the lion's share of the gaming market
Given that you need a bleeding-edge $1000 PC to run Oculus at a smooth, nausea-free 70hz, I don't see how Sony is going to get similar performance from a 2-year-old $400 console.
Maybe a couple generations down the road, but not in the next few years.
That completely depends on how graphics intensive a particular game is. Sure you won't be running the Witcher 3 at 90 fps, but it's definitely possible if you make a game that is more stylized and less photo realistic.
They're also apparently using some kind of frame interpolation to run 60hz games at 120hz. How well that works to stop nausea I don't know, but the reviews from early demos I've seen look promising.
My goodness. How many of these sales pitches for Couchbase do you intend to insert into this discussion?! One time, that's cool. But you're way, way, way over quota. Give it a flipping rest.
Man, this is an example of how to shutter a service gracefully. 1 year heads up and an open source replacement for their service with export tools to port the data in to a format that replacement can use.
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?
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
Ugh. This is why you don't build on proprietary stacks like this. I've detailed tonnes of complaints I've had about the platform itself being awkward and buggy in previous HN comments, but this is obviously the #1 reason not to.
If Facebook can shut down a service this big, Google or Amazon can too. Moving a VM is (reasonably) easy, but porting an app from proprietary backend X to another is hard.
No, this is just why you should architect your applications so that the backend isn't all over the app, but instead limited to the outskirts. Then you can change providers at will.
>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.
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.
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!
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 the towel on what seemed like a good plan to gain a foothold in the cloud space.
Either that, or they're not really shutting down, and they just want to get a bunch of free labor from open source developers before migrating to an enterprise support business model.
Isn't Instagram still using AWS for some of their infrastructure? They had a big blog post about moving but if i remember correctly there was article about instagram getting hacked via S3 bucket keys a couple months back.
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.
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.
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
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.
"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.
One of the reasons you need to pick hosted services very carefully is just this type of scenario. Especially when you are deciding where your data lives.
I give a tremendous amount of respect though to the Parse team for open sourcing the server. Like holy crap they released their entire code base. It must have been especially tough since you have to go through it and clean everything up. Too bad they didn't include the commit history (I certainly understand why they did it). Commit histories are generally the most interesting.
I was just looking at Parse & Firebase for the potential back-end on a biz app I am currently developing. I decided to install DreamFactory on AWS with DynamoDB because I felt uneasy relying on the others. I have been burned multiple times by both Facebook & Google shutting down API's.
It was fairly painless getting DreamFactory setup.
I give props to Facebook for giving such a long notice though. That should be more than enough time for app developers to switch.
Currently using Parse for Push notifications (it's simple to send a request to Parse and it handles iOS vs Android issues).
Is there any tool out there that has similar functionality? Ie. you register all your users devices there and they simplify the sending of push notifications.
Free - what's the catch? I don't want to have the same problem all over again. Forget the fine print, the body text is really hard to read superthin gray text on white.
We make revenue from products that help companies with advertising and competitive research. Our push service helps us collect the data necessary to make this work, similar to services like Flurry Analytics. So we're happy to provide it for free. Happy to go into more detail via email: contact@onesignal.com
We started using Parse for the simple push notifications, stayed for the DB.
Also had looked into Urban Airship but it's several times more expensive. I do want to pay for a service so it doesn't go away, but at those enterprise prices I'm definitely better off setting up my own APNS server.
Hey, we are migrating from Parse and planning to use PubNub.
With parse,
1. we use channels to subscribe.
2. All the cross platform thingy like iOS/Android/Windows is managed by Parse.
I have a couple of questions.
1. Do you have a way to upload all the channels+device tokes and stuff that we can extract from Parse?
2. What does the "Daily Active Devices" - 100 for Free tier mean? Does it have to do with Push notifications? because we are NOT using it for realtime connections.
We will have about 7-8 thousand devices registered and < 1 million push notifications. So are we still under the Free tier?
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 use Google Analytics, Flurry Analytics, Facebook Analytics and Fabric all with custom events. Fabric is great for real-time. Mixpanel seems to be extremely costly depending on what type of app or game you have.
For broadcast push notifications, I use PushWoosh. They have a lot of features that Parse Push doesn't for broadcast notifications.
As for the in-app client-based push notification triggered by liking or commenting on a post or profile, I have no idea how to replace that without Parse. Hopefully they'll included some sort of guide to help with that migration.
a) release open source versions and announce pricing increase in the future.
b) reduce people using the free 30 transactions / second limit.
c) maintain in maintenance mode indefinitely.
I just don't get why companies shut down services unless they're folding them into open source projects (like Freebase into Wikidata). Maintenance mode seems cheap to me, but maybe I'm missing something?
I am most curious about Facebook's strategy for this. Total guesses - but maybe they have another developer platform in the works? Maybe it's just the focus on core businesses, but it is most curious.
Keep in mind that this is Facebook, so it's likely they just had better things for those developers to do that would generate the company more revenue. It's not in Facebook's interest to keep a business running that's barely breaking even, especially when they can take the team and put it to use elsewhere within the company. (Not that I know what Parse's financials look like, but I'm guessing they aren't making boatloads of money.)
My sympathies to any workers displaced by these events, but I'm happy. Parse is a bad product: it has weird quirks in normal usage but most importantly scales abysmally. I'm thrilled to have ammunition to justify moving away from it.
Love love love the open source angle however, and wish more sunsetting products go this route.
"...back-end tools for mobile developers that help mobile developers store data in the cloud, manage identity log-ins, handle push notifications and run custom code in the cloud."
AFAICT, it was doing all the mundane work you need to get a modern mobile app up and running. So, developers could concentrate on the business logic of their application and leave the rest to Parse.
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.
Kudos to the Parse team for many things, including a much more decent exit than many others. But aside all my admiration for all their achievements - all beyond my abilities - let me ask you, hackers of the world, is this what we really want, if/when we build something so awesome? I do prefer to hear DHH talk stuff like "Basecamp is my life's work".
Totally disappointed with this announcement. Facebook is making billions of dollars of profit but can't keep up the lights at Parse. I will think twice to jump on these platforms next time. Now, I am more sceptical of using ReactJS, ReactNative and other stuff from the FB spearheads. Perhaps a high time to learn typescript and angular2.
ReactJS is a no-no from the get go. Facebook's Patent grant on what is supposed to be an "open source product" is ridiculous: https://github.com/facebook/react/blob/master/PATENTS. "If you ever start a patent conflict with Facebook in court, (worse but even more likely:) or if Facebook starts a patent litigation against you, you LOSE all your rights to use React in ANY product throughout your company and MUST stop using it at once in your code!" Imagine how that can bring a team down.
If folks know of anything out there that works like React (I like the ideas, including JSX) but isn't hobbled simply by mis-virtue of being "backed" by the characterless evil that is Facebook, kindly enlighten me, I will use it.
I'm actually wondering if the new "open source" Parse code will have the same Patent horror built-in, and if yes that's even worse considering backends can be even more complicated and important part of a company's infra.
Also, I'm sure there are people saying "hey, your work may not be significant enough to cause a Patent violation with Facebook so you and the majority of library users are safe". Sure, that is likely true. But it's about the principle.
Speculations on why the shutdown: Apple CloudKit is gaining momentum. Google is predicted to come out its own offering for Android based on Firebase. Facebook wants focus on its Messenger as a platform, rather than 'supporting' Apple and Google's platforms. My 2 cents.
A year ago when I rewrote my startup's product in AngularJS I was on the fence between Firebase and Parse. Built prototypes against both and ended up going with Firebase for a few reasons - 1: price, 2: owned by Google and not FB and 3: the whole 3 way data binding thing.
Awesome to see them releasing code for the backend but I'm finding this trend really disturbing - relying on 3rd party services for everything.
Doesn't anyone remember back in the day (like 5 years ago hah) when programmers / admins actually bought software and ran it on their own servers and didn't "rent" it? I know, crazy right? To own software and if the company went under, things could still be fine for a while longer.
Maybe it's time to consider my use of Firebase and go back to the way things used to be.
Suddenly, Apple's CloudKit doesn't seem so unattractive - but at the same time I fear it will face a similar fate. Anyone have any insight about whether it's "safe" to build upon? Is there yet an Android solution for connecting to their REST API?
One thing that I haven't noticed in the comments is that the released server is parse API compatible. It is not the parse server, and so you aren't guaranteed the same things you are guaranteed from the real parse service.
The "real" Parse service is built to power hundreds of thousands of apps. The OSS Parse Server you run yourself would only need to power a single app. Two very different use cases.
Yes, but it seems that everyone thinks that this is the "Parse Server" being released. It's not, it's just an open source compatible API.
It's important because a lot of the powerful features of Parse aren't included in the new open source server (analytics, config, push). Saying that Parse is open-source seems to imply that these powerful features are available.
Hey guys, you can try www.backand.com which gives you anything that parse had to offer and much more. Real time, hosting, DB and server side action is just a bit of what they give you. Oh and the best part, it's free.
Unlike Facebook, backand main business is being a Baas. It has a lot of developers and fully backed. In addition, Backand's unique feature is that you can get the database connection and the server side configuration any time you want!
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?
Interesting. I guess I bought into the PR/propaganda that said Parse was a huge success and good acquisition for facebook. Never made sense to me why one would use such a service anyway.
I used Parse a few years ago to serve as a backend for a simple event aggregation app. It was incredibly simple to use and integrate with. I probably spent on the order of ~1hr reading documentation and another 2 hours doing some quick and dirty implementation before having a functioning Android app. It's too bad it's shutting down, but I can't say I didn't see this coming after the Facebook aquisition.
Seems telling that Facebook chose to shut it down rather than spin it back out on its own or sell it. That implies the economics of it weren't working.
Kudos to Parse/Facebook for a somewhat graceful exit.
However, i find it extremely foolish to shut this down completely from Facebook's point of view.
Sure redeploy all the gun developers to other FB products, but you can't tell me FB could not afford to hire some devs to maintain this service. They could have sold the service to another company too.
This just gives Facebook more bad vibes from the dev community.
This thing has disturbed everyone who have hosted their apps on Parse platform, they are looking for an alternate solution. I am also one of them.
I have already talked with various app development platform providers and check their platforms. I found Configure.IT as the nice solution compared to other platforms. Actually my 10 to 15 apps are on Parse. So I am bit worried about it. Now After checking all the solutions, Finally I reached to a decision.
I also want to guide all the people who are passing through the same situation as I am passing. I have checked all the features and facilities provided by this platform and also talked with the authorized persons of this platform. Really a genuine one.
So finally I have given the project of my apps migration to Configure.IT ( http://www.configure.it/ ) and they are doing it very nicely. Thanks to whole team. Thanks a lot.
I haven't worked with Parse, but the announcement reminds me of something I decided to do as much as I can.
We sometimes choose to build features on top of third-party vendors' services, and the reality's that unless that third-party derives decent revenue or primarily provides that service; one shouldn't expect that the service will always be available. Twitter was a good example, Google SEO is another, where people who were relying mostly on search traffic got wiped when algorithms were changed.
It takes longer at times, and seems like reinventing the wheel, but for features that I deem to be very useful to my users, I choose to roll out the relevant underlying detail myself. In most cases there are often already third-party libraries that can help with bootstrapping the features. I'm glad that the parse-server is available so people can run their own local instance though.
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 :
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?
We are gutted by this and so are our clients, so we are working to create a Parse Hosting service for both our apps and the other developers in the community. For more information checkout http://parsehosting.net
Parse was the go-to platform for those who wanted to concentrate on their end product.I know people with (day to week)-old ideas who could set up the complete application using parse.It not only made life simpler for everyone but greatly supported rapid prototyping and not having to go through the hassle that comes with building your own stack.Yes I know there are combinations of several SAAS and IAAS which can fill the void,but no one can come close to the single stop solution that Parse provided. I hoped that Facebook would do with parse what Twitter did with Fabric(Yes I know that Fabric has ads as a business,but crashlytics is a god send for mobile developers). Nevertheless I hope more Parse like solutions are yet come.
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.
Can anyone explain to me what Parse actually is? Based on a quick read of https://parse.com/apps/quickstart#parse_data/mobile/android/... this is basically a cloud-based key-value store, is that correct? And the value-add is basically that you can subscribe to stuff, and they did all the finicky cross-platform stuff to get it to work in mobile devices?
And this is something that any competent developer could write in-house in a few days, but what they were selling it for is a lot cheaper than a few developer-days?
That's correct, give or take a few other features.
The selling point of Parse, at least to me, wasn't "this is complex or particularly high-quality engineering". It's "you want to bang out an MVP in a day. Awesome, we took care of giving you a server to shove shit on."
Hm. I personally haven't used Parse and I didn't even know they were with Facebook but I've seen it mentioned as a pretty popular back-end platform for Android apps (for example). What's the alternative then? AWS probably then?
I would not tie myself to a Cloud Platform but use open source stuff like docker which can be moved between Clouds. Btw, There's CloudBoost.io which is an alternative to Parse and is both on Docker (self-hosted) or as a managed solution at CloudBoost.io
Would you mind adding a "Disclaimer: I'm the co-founder of CloudBoost.io"? I've got nothing against you promoting your project when people need alternatives, but it's important that people realize you've got a stake in it. Like so:
Disclaimer: I work on Compute Engine, but not Firebase ;).
I was reading an article just the other day saying how the web has made people feel the need to self censor, "apologise in advance", add disclaimers to everything they write, etc. because they're afraid to offend anyone these days since some people online are nuts. Unfortunately I can't find the link now...
Disclaimer: I don't like disclaimers. Just write what you believe; unapologetically be you.
The parse blog crashes my Firefox browser. Even in safe mode and without javascript the browser crashes.
Also, trying to close my Parse account is impossible. Then I found this on their FAQ:
"Currently, there is no way to delete an account. You can just stop using it; we won't spam you."
But they did spam me, I got an email from "FocusVision an independent research firm via Facebook." asking me to take a survey about Parse. I have nothing to do with Facebook, never had a Facebook account, never will. I'd forgotten Parse was acquired by Facebook.. now I remember the "it won't change anything, we're not going anywhere" blog posts from 2 years ago.
My company is about to get acquired for our technology. A huge part of the tech relies on Parse. I mean they were charging for it! Who would think that they will shutting down?
I guess we'll have to rebuild that part from scratch starting right now.
I don't understand their decision. Developers are crucial for Facebook's success as platform, and the amount of distrust and bad-will they just gained would seem to far outweigh their cost savings in grand scheme of things.
Dang. I literally just finished building my first app with React Native/Parse two days ago. Was really amazed by how easy the stack was to get production ready, but now? Heigh ho, heigh ho, its off to work I go... :(
I think someone posted this on another thread somewhere (and sorry I could not dig it back up). With MongoLab and Google Cloud Platform, I literally just re-specified the Parse App ID and Keys and got the Parser server up and running in matter of minutes: https://cloud.google.com/nodejs/resources/frameworks/parse-s...
Yes, with limitation on quite a few things now. But it's a good start.
Next thing to explore is how to scale this thing out.
Parse was how I got my first backend needing apps into the App Store. Always thought they were a great company and really set the bar for how to build and document an API. Sad to see them go, but wish them all the best.
Hi Guys, I am trying to set up Parse Server and a Mongo DB locally on my mac. When I run Parse Server, I got this message "DATABASE_URI not specified, falling back to localhost". However, I did provide the DATABASE_URI. Probably I am so noob and didn't fully get it. The following is what I provided. Please advice me.
var api = new ParseServer({
databaseURI: 'mongodb://localhost:27017/dev',
cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
appId: 'xxxx',
masterKey: 'xxxx',
});
We believe that not relying on another hosted BaaS solution is the best strategy. Just because of this we have created an API generation tool called API Plug that can benefit mobile and backend developers. You can export MongoDB from Parse right now. After that you can generate & download your own REST API source code in any language you need in minutes from https://apiplug.com Then you could deploy on your own server and have the full control of your backend.
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.
Former employee of Kinvey here. But I absolutely loved working there and they have an incredibly formidable offering which I personally feel surpassed Parse.
I think Parse is an awesome platform and was really well documented. I used it for building my app, and will probably end up migrating to my own parse server and then decide where to go from there.
Parse really made it easy to get an app running. Especially a couple of years ago, when api's were complicated.
I'm going to miss the push notifications, I just implemented them and they work really well. Hopefully an open source solution will get released so we can continue using them.
If you're making (mobile) games and looking for a replacement, I cannot recommend Gamesparks[1] highly enough. Their documentation is way behind Parse's (which has excellent docs), but their features (relevant to games) and customer support are far superior, and they are actively working on improving their docs.
When the news first hit I was a little disappointed but after reading through the "what to do next" post I am extremely impressed by the way Facebook are handling this. A year to let us all migrate is more than generous, and an open source server will allow us all to continue to rapidly build our applications. I don't mind fiddling around with scaling a little through the AWS console.
Hi Guys, after a few hours of googling (trust me, I spent my whole Sunday being so pissed of at Facebook and researching alternatives to Parse.com), I arrived in this awesome page. I read a few comments below and it seems like I just found an oasis! With this open source project, do you guys think it would be still possible for an app to support FB sign in features?
I used Parse for a dozen projects, but none in production, and all were free. To be honest, I loved how Parse allowed me to focus on the App/product without having to worry about APIs and backend.
However whenever I'm serious about an App I end-up investing in some PHP or Node .. This is probably true for a lot of people and this is why it is probably shutting down.
It would be nice to see the Go server that powers Parse.com's production servers. I recall in Gophergon 2015 there was a presentation on how they migrated from Ruby to Go. https://gophercon.com/talks/rebuilding-parse/
It is a sad day and I feel for the developers who got caught in the situation. If migrating to your own server is not an option, consider Backendless (https://backendless.com). We are stable and healthy and we have a team to help you with the migration of your app.
Many thanks for a great product, for giving away the server code and migration tool but...no thanks. The whole point is that many of us don't want to run the back-end. We cannot afford to do so, we are not fully qualified to do so, our clients will not pay us more to do so.
Anyone else selling a similar service? I'm up for grabs!
So, just some unanswered questions in my mind concerning startups that get bought out then shut down.
Do they end up creating more value than was invested into them in the course of their lifetime? Who captures most of this value? What does this mean for technological innovation and increase in productivity in general?
I've used Parse for all of my apps but I don't really understand what goes on between my client (iOS apps) and them. Reading on this would help a lot before trying to host the open source Parse Server by myself. Can anyone recommend tutorials/videos regarding hosting your own backend?
[Kii employee here]
We've been getting many inquiries at Kii Corporation from Parse customers about migration. To get you started: https://en.kii.com/parse-migration/
Is there an opportunity for a 3rd-party hosted Parse service? Seems like that may be an option for the folks who are currently using Parse and need to move: someone to basically run the open source service on top of AWS/Linode/Digital Ocean/Google Cloud for a nominal fee.
Parse is a great provider for push notifications, having only really gone down once in the time we've used it (and also being, well, free). I didn't use any other part of the system because we had our own databases and whatnot, but it is great for push. It will be missed.
Coincidentally we recently added MongoDB to our range. So, if you don't want to do devops yourself, our fully managed stack may be an interesting migration path. First app is free. https://cloudno.de
Very very disappointing. Parse was a great platform and Facebook killed it. I guess it's going to be full stack AWS all the time forever. They shouldn't have bought it if this wasn't going to be a core part of the business going forward. Boo, Facebook!!
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.
Suddenly! I just finished pretty complex app which relies on Parse, can anybody recommend some alternative service? I have looked at Kinvey, but it seems too expensive. Does anybody have experience with Backendless?
I always thought of Parse as a service for someone too lazy to setup mongodb. But to be serious, I think that was a nice tool to get ideas up and running for testing purposes. Running in production? Hell no.
I guess it depends on what your aims are. Are you new to mobile development in general and just want to learn how to develop for your preferred platform(iOS, Android etc..)? If thats the case then definitely use Firebase or any other backend as a service for that matter. This will allow you to focus on building your app and not have to worry about implementing an API that provides access to your mongodb database(this would also be a worthwhile exercise). Hope that helped.
Damn, I just added Parse to a small project. Does anyone have a suggestion for a good service that handles Push notifications like Parse? I really don't want to set up my own server for this.
I would like to see a detailed explanation from Facebook on the business front for closing Parse. Developers would now be skeptical about using any Proprietary service for their backend.
If you want to move to an other BaaS, ZetaPush provides NoSQL as a service, File storage as a service, Search as a service and lot's of other things for mobile, web, server and IoT
Since this was clearly a Facebook decision, Facebook should have announced the shutdown on their own blog instead of humiliating the Parse team like this.
OK. i ve read all comments here. literally. why no one mentioned baasbox? i am building a mobile app with parse and now considering to move it to the baasbox on my own server. And no one here mentioned them. something wrong with it?
What is Facebook retaining? There must be something they are holding onto. Would it make any sense for FB to give the original founders the option to buy back Parse? With them open sourcing most of the product, what could they still have?
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 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.
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.
This announcement will have a huge impact for the mobile dev community that relies on Backend-as-a-Service systems. I personally think that Facebook had several reasons to shut down Parse:
1) The technology stack was really fragmented and often rewritten in large parts. I still have this statistic in mind how their 200 Rails API servers were only able to serve 15 requests/s each [1]. If you look at the database technology inside Facebook, there is much superior infrastructure that was never really integrated into Parse (Haystack@OSDI'10, Tao@ATC'13, F4@OSDI'14, Extended Apache Giraph@VLDB'15, RocksDB, etc.)
2) Parse did not have a core competitive advantage: it was just the first company to whole-heartedly pick up the BaaS-paradigm with sufficient man power and a good understanding of developers' needs. The technology itself was not particularly innovative in any way, just (mostly) solid engineering. However, there remained really basic limitations that were never addressed [2]. For instance the only (!) way to safely handle concurrency control was through counter data types.
3) The model of Parse promotes independent apps and websites outside the Facebook universe.
4) The pricing in increments of guaranteed 30 requests/s was okay for simple apps but absolutely useless for anything beyond that. In particular for websites which as of 2016 do an average of 100 requests per page load [2] a single user can leave a Parse app rate-limited or down.
The main asset of Parse were their great client SDKs and well-written documentation.
This is why we made a plan: we will fork the Parse SDKs to offer seamless continuation of apps relying on them, including Push and the other features dropped in the open-source Parse Server. We opted for this approach as the Parse Server implementation on Github looks really brittle and the convoluted Parse REST API is really not an option. By doing this we hope to provide a scalable and long-term solution for developers looking to continue their Parse-based apps.
Baqend [2] is a pre-seed startup founded out of the database research group at the University of Hamburg (Germany). Our product launching into production within the next months uses a new approach to consistent web-caching reducing latency in common web workloads by up to an order of magnitude [5]. It is due to this background that we very eager to not only provide great usability (which Parse also did) but also acknowledge the need for complex data processing: low latency access, partial updates, continuous queries and ACID transactions.
Facebook's stock is up 15% today. If they're this quick to kill off products and services then long term I'm bearish on them. Zuckerberg just came back from paternity leave and he announced a one month vacation next month. I don't think his head's in the game. Get rich and stop trying I guess?
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.