Facebook is closing Parse
blog.parse.com
blog.parse.com
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.
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
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!
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.
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).
I dont' think running my own servers with Parse is viable as Parse won't be updated from now on while other BaaS will stay updated and keep improving
We'd love to know what limitations you've run into and how we can do better! Send me a tweet: @startupandrew
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.
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.
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.
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.
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.
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.
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.
i'd love to figure out how to lock people into expensive shitty projects that belong to me
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.
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.
That said: the app sends basic notifications when in-app, user-initiated events of interest occur.
The server code is PHP, based off of this fantastic little tutorial: http://www.raywenderlich.com/32963/apple-push-notification-s...
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.
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.
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?
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.
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.
Microsoft supported products: Azure - six years, .Net & Active Directory - thirteen years, SQL Server - seventeen years, Visual Studio - nineteen years, and Excel - twenty nine years.
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:
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?
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.
Especially given the fact that the very goal of most VC companies is acquisition.
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.
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...
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".
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.
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.
The "price of progress" is suddenly not being able to play WhackAMole 3000 on your mobile phone on your way to work?
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.
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.
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.
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.
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.
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.
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.
> VR is a huge opportunity and is likely to be the entertainment medium of the future
Is it? Last time it was 3D. And before that..
Did anybody actually like 3D TV?
VR is a revolutionary technology. Much more akin to smartphones. It's not hard to imagine the possibilities that VR can bring.
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.
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.
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.
You are right with AWS.
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.
But of course people will keep doing it, and keep complaining when the inevitable happens.
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.
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.
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.
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.
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.
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.
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...
From startups to the Fortune 500, hundreds of
thousands of developers *trust us*.
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.
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.
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...
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....
https://twitter.com/Firebase/status/692845862527995904
> Not a great day for app developers :( Firebase is healthy & actively working on many new exciting features here at Google #parse
Disclaimer: I work on Compute Engine not Firebase (but I sit next to them).
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.
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.
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.
Disclamer - I work at Taplytics!
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
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.
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?
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.
Anyway, I love parse! Cool it's open source now.
"A [Single Page App] will lock you into a framework that has the shelf life of a hamster dump"
Seems like that could be said about a lot of infrastructure services out there as well.
https://en.wikipedia.org/wiki/Parse_%28company%29
"...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.
I feel like that's a relevant question I have for most HN posts
Another data point for the "Is PaaS dead?" conversation.
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.
It's faster than React or Angular 2 in one benchmark methodology: http://www.stefankrause.net/wp/?p=218
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.
I want to help put your mind at ease. Google is 100% behind us. If you have specific concerns, please ping me on Twitter: @startupandrew
https://developer.apple.com/icloud/images/cloudkit-dashboard...
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.
> "Backand’s proprietary technology".
This means, if Backand will be acquired and shut down, all my time spent on learning specifics of Backand infrastructure will be wasted?
Are there any plans to open-source the platform? That would give some guarantee and peace of mind.
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.
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.
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.
when a venture capatilist leaves the team things are not going good somewhere ;)
https://github.com/Mparaiso/playground ( a jsfiddle lite directly available on github , the UI is angularjs : https://mparaiso.github.io/playground )
So thanks. You were the best BaaS feature wise IMHO.
EDIT: however just one point : you took 1 year to rewrite your API in Go, which yielded performances but the product didn't evolve that much in the meantime because of the rewrite, was the experience positive or negative?
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.
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?
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."
Disclaimer: I work on Compute Engine, but not Firebase ;).
Disclaimer: I don't like disclaimers. Just write what you believe; unapologetically be you.
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.
Next thing to explore is how to scale this thing out.
var api = new ParseServer({ databaseURI: 'mongodb://localhost:27017/dev', cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js', appId: 'xxxx', masterKey: 'xxxx', });
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.
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.
Parse was on track to disrupt the cloud. Why do you need a full backend when you can easily define APIs and access them through mobile and web?
> Apps currently hosted by Parse include Food Network, Hipmunk, iBart, Anypic, and Travel Channel. There are 100,000 apps using Parse, Graham says.
Article is 3 years old but wonder if they've moved on from Parse?
VEVO, Volvo, Udacity, Eventbrite, Orbitz, Ebay, Groupon, Hipmunk, MTv, Playtika, EBATES, SAMSUNG and many many others
https://webcache.googleusercontent.com/search?q=cache:ZL4JyM...
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.
"Facebook’s Parse shutdown has a lesson to all tech customers"
https://medium.com/@pauli/facebook-s-parse-shutdown-has-a-le...
Firebase. That's it. Just one word. :-)
Anyone else selling a similar service? I'm up for grabs!
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 basically now have the following assumption by default every time I see a new startup:
What ever they are doing now, it will probably be shutdown within the next 4 years (assuming it gets any success at all in the first place).
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.
The thing is, there are articles guiding me through using Firebase. I'm not sure there are articles telling me how to setup mongodb and where
I used Parse. But I found it's expensive if you want to use some Pro features. I built my own server on a cheap VPS later.
I chose Parse because it looks better than Firebase... this latest development is beyond me. Such a promising product...
After a few turns at the merry go round the newbie developers learn this hard lesson.
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).
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.
We'll post a detailed plan on our blog, soon.
[1] http://blog.parse.com/learn/how-we-moved-our-api-from-ruby-t... [2] http://profi.co/all-the-limits-of-parse/ [3] http://httparchive.org/trends.php/ [4] http://www.baqend.com/ [5] http://www.btw-2015.de/res/proceedings/Hauptband/Wiss/Gesser...
Remember this comment.