parse

The Big List of Alternatives to Parse

High Scalability

Feb 2, 2016 — 20 min read

Parse is not going away. It’s going to get better.
Ilya Sukhar — April 25th, 2013 on the Future of Parse

Parse is dead. The great diaspora has begun. The gold rush is on. There’s a huge opportunity for some to feed and grow on Parse’s 600,000 fleeing customers.

Where should you go? What should you do? By now you’ve transitioned through all five stages of grief and ready for stage six: doing something about it. Fortunately there are a lot of options and I’ve gathered as many resources as I can here in one place.

There is a Lot Pain Out There

Parse closing is a bigger deal than most shutterings. There’s even a petition: Don't Shut down Parse.com. That doesn’t happen unless you’ve managed to touch people. What could account for such an outpouring of emotion?

Parse and the massive switch to mobile computing grew up at the same time. Mobile is by definition personal. Many programmers capable of handling UI programming challenge were not as experienced with backend programming and Parse filled that void. When a childhood friend you grew to depend on dies, it hurts. That hurt is deep. It goes into the very nature of how you make stuff, how you grow, how you realize your dreams, how you make a living. That’s a very intimate connection.

For a trip through memory lane Our Incredible Journey is a tumblr chronicling many services that are no longer with us.

Some reactions from around the net:

maxado_zdl: F*ck you facebook!!!!!!!!!!!!!!!!!!!!!!!!

pacp_ec: Damn it Facebook only George R. R. Martin is allowed to kill my heroes

Mythul: I really hate facebook right now ! Thanks for screwing up my apps with your bad business model!

GIVENOWIO: Thank you for what you’ve built. Our app is backed by Parse, and you’ve made it possible to help real people in a critical time because of how well you executed on your vision. I’m sure you’ve heard the same from the myriad other companies you’ve enabled thanks to the mBaaS innovations that Parse pioneered. I’m dismayed as everyone else that Facebook’s bean counters missed this immense forest for the trees of immediate profitability. They won’t soon regain developers’ trust.

Mufro: Damn. We've been slowly migrating our smaller apps to Parse as we make annual updates. Now we're trying to figure out what we're gonna do... go back to the pain of rolling our own server backends out? This leaves a pretty big hole in the market IMO. I don't know of anyone who gets you off the ground as quickly and affordably as Parse does. It's been a joy to use their product, but I knew deep down it was too good to be true. I guess we'll have to take a look at AWS again, maybe Azure. We use Firebase in another project, so we might check that out too. This sucks though.

samwize7: When Facebook acquired Parse, I thought it is good news since they ain't profitable, and now they have a backing of a giant, who tried hard to woo developers. I built many mobile apps using Parse, and has always been a fan of how they build a product for developers. Their documentation is awesome, their free tier is generous, their SDK covers widely. Today, their announcement is a sad news. And once again, proves that we can't trust Facebook.

clev1: This literally just ruined my day....I've got 2 major projects near completion that I've been using Parse as a BaaS for. Anyone with experience know how difficult or a transition it is to switch to Firebase?

solumamantis: I just can't believe the service is being retired... I started using three months ago - my new app coming out soon is completely reliant on it..... I will have a look on Firebase, but honestly I think i will build my own Parse/Node.js version and manage it myself....

changingminds: What the f*ck. Wtf am I supposed to do with 120k users who currently use my app that uses parse? I gotta redo the entire f*cking backend? F*cking bullsh*t.

manooka: My entire startup relies on Parse. I developed the website and apps myself as this was perfect for me as a Front-end developer without having to worry about back-end servers/databases etc. This is SERIOUSLY bad news.

stuntmanmikey: I'm a full-stack developer who is part of a startup that depends on Parse. As the only developer, the amount of time we've saved NOT having to write a data access layer and web service layer has been a windfall for us. Now I'm left to either switch to a similar product (Firebase just doesn't have the same appeal to me) or implement the backend myself at great cost.

neckbeardfedoras: The thing is, most of the folks using Parse probably use it because they're not full stack or back end developers. Removal of Parse means more time or money spent on resources to manage a back end system.

Why did Facebook Shutdown Parse?

There are a lot of different opinions: Parsing Facebook's Parse Shutdown, Parse and who can you trust?, Facebook is shutting down Parse, its effort to take on Amazon's cloud supremacy, Why did Parse fail?, Why Facebook’s Parse shutdown is good news for all of us, Facebook Is Creating A House Of Cards, Why did Facebook discontinue Parse?, Instant Analysis: Facebook to Shut Down Parse, They never wanted to host your app. The real reasons why Parse shut down.

Reason: It Was the Longest Acquihire in History

Nah. They would have shut it down immediately.

The full quote from Sascha Konietzke is: "they never wanted to host your app, they just wanted you to use Facebook login." Great discussion on Hacker News. That's a really long ways to go for a login, so this doesn't really pass the common sense test.

Reason: Facebook Lost the Will to Keep Going

We get this interesting take from tsunamifury:

Click-bait speculation.

Word in the industry was that after two failed attempts to move from AWS to Facebooks metal failed spectacularly and massive attrition after vesting -- no one was left to make it work and Facebook lost the will to keep going.

The more important lesson was that a failure to port a stack from AWS to FB servers caused Facebook to take a $1B write-down. Startups should reconsider their metal, as future acquirers will likely heed this lesson strongly.

It's not implausible, it happens all the time, but we would need some insider knowledge to know anything real about this sort of speculation.

Reason: Cut Your Losses

It may be as simple as when Facebook acquired Parse they weren’t the giant profit machine we all know and fear today. They were searching for a way to make money and thought the cloud business might be it. Amazon, Google and Microsoft are better at cloud services and Facebook cracked the code on the whole mobile advertising thing, so they don’t need a low-margin Parse anymore. Facebook isn't in the infrastructure business.

They truly do want “to focus our resources elsewhere.” So, cut your losses. Parse was a cheap experiment. Makes sense. But why now?

Reason: Strategic Alignments Were Not Aligned

Charity Majors, formerly of Parse/Facebook, says in How to Survive an Acquisition:

One of Facebook’s internal slogans is something like “always do what’s best for Facebook”. I never gave a shit about Facebook’s mission; I cared about Parse’s. I remain incredibly proud of everything we accomplished for Parse, MongoDB, and RocksDB. If only our strategic alignments had, well, aligned.

What this means isn't exactly clear, it doesn't preclude any of the other reasons, but I love the sentiment.

Reason: Messenger is the New Center of the Facebook Universe

Where does Facebook want to put their resources? Facebook Messenger. Messenger is the new message based application platform for Facebook’s walled garden. That makes Parse redundant. Off strategy.

While Messenger might cannibalize the advertising business as advertising over messaging hasn’t been a winner, it could bring in WeChat like transactional income, which has longer term growth potential.

Which flows into the obvious question: why did Facebook choose to shutter Parse instead of selling it off? Why not perhaps make a little money on the sale, or on a spin-out, and in the process support the many customers they’ve been aggressively courting all these years? They don't want to lose engineers has to be part of it.

Answer: Facebook wants you to build applications on top of Messenger. By shutting down Parse Facebook is hoping to drive a lot of developers to Messenger.

That’s one line of thought anyway. While deliciously Machiavellian, it doesn’t really square with Parse open sourcing their server and providing a data migration tool. Remember, not long ago Parse open sourced all their SDKs. Not exactly the actions of a group hell bent on Messenger domination.

In short: we still don't really know. But I like this reported quote from an insider: "I would write something but it would be so simplistic that nobody would believe it." Now that's something I can believe.

Did Kevin Lacker, cofounder of Parse, regret selling to Facebook? His answer on Quora:

I don't regret it. The nature of startups is that they usually fail. The nature of acquisitions is that they usually fail. So you just have to accept that you are doing something very risky, when you start the startup in the first place. If you regret every single thing that doesn't work out along the way, you'll be afraid to start something new and ambitious. YOLO

Can developers still trust Facebook?

@TravisBloom: shutting down @ParseIt has removed a lot of my faith in #MBaaS. Such a fantastic product, real shame

nodamage: 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?

josh2600: 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...

Of course developers can’t trust Facebook. Developers can’t trust anyone. Developers should always have contingency plans. It’s a dangerous world. Exit strategies aren’t just for startups. If you plan on using React Native or Oculus, have an exit strategy.

Yet court Facebook you will. Facebook is the bouncer in front of that hot club where 1.5+ billion users are partying like it’s 1999 and every developer wants to get it. Apple has their own club. Blessed are the aggregators. Developers need to go where the users are so they’ll always take the risk. Just go in with Eyes Wide Open.

What Lessons Learned?

There are lots of lessons to learn: Lessons from Parse, Parse shutdown lessons, Facebook’s Parse shutdown has a lesson to all tech customers, Why you shouldn’t be upset if you built with Parse, What The Death of Parse Proves: It’s Not About Who Owns the Platform, Why-decoupling-your-code-matters-a-Parse-story.

Dave Verwer sums it up nicely in a well balanced mature viewpoint:

It's always a tricky balance between using a BaaS platform like Parse, or building everything yourself. We're all aware that any service we rely on could potentially go away at any time but there is none more disruptive than your entire back end! On the other side of the argument, you could spend years building everything you need from scratch and completely custom, then have the app not gain any popularity and have it all wasted. It's a tricky problem and there's no right answer.

The Number One Lesson: Don't Rely On Other People’s Code

Before we jump into all the people saying the smart play is to only ever rely on your own code, here’s a counter viewpoint:

HadADat: Depending on a third party is always a risk, sure, and not ideal but if you're trying to work quickly and cheaply technologies like Parse are an amazing tool. So many apps/companies couldn't (or didn't) make it without tech like parse.

@jeffiel: "But seriously developers, trust us next time your needs temporarily overlap our strategic interests. And here's a t-shirt."

akarve: 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.)

And then there’s the eternal question of where exactly does using only your own code stop?

bikamonki: 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 rhetorical of course, all the answers are no. What exactly is wrong about trusting one more layer to 'experts'?

Now, back to your regularly scheduled advice:

15458434: The only lesson here. Don't go for platform with a large free tier. It's better to start developing something with a platform you to start paying early on. So that the platform may be alive longer. And why? A lot of apps don't get that many users. And they eat up resources. Yes, it will attract a lot of users to that platform. People love free, but then... you might not get it viable as a business. Just like Parse.

chriswaco: As an old programmer who has been in the software business for 30 years, I can tell you from personal experience that you should always be careful about tying your business interests to someone else

20InMyHead: The lesson is to follow good programming and architecture practices; never code to a specific vendor API. Abstraction, encapsulation, and isolation are your friends. Even if one vendor is providing multiple services, design your code so they can be separated. Additionally, I find it best to avoid client-side vendor libraries, especially for simple stuff. There's no reason you need a client library for something like just remote notifications.

preslavrachev: TBH, the whole BaaS ideas seemed somewhat DOA from the beginning. I don't think we should react surprised, as providers start fading away one by one. It's just not sustainable for several reasons. Any team with more than three developers at hand, will prefer the flexibility of using their own backend solution. This leaves BaaS providers having to serve the needs of individuals, or very small teams willing to prototype an idea. In any case, far from being able to pay enough for a BaaS solution and keep it alive. I've tried a couple BaaS solutions, including Parse, and think that the tradeoff of having to integrate it, vs the actual flexibility you get out of it, is just not worth it. In all cases, I ended up developing and deploying my own backends.

@_paulbuchanan: we are paying for Parse and that didn’t help us. You and only be sure about what you control yourself.

s73v3r: I'm not saying not to use Parse at all. I'm saying more to do stuff like not have your classes inherit from PFObject, and don't call Parse methods in your main app, but rather hide them behind interfaces.

nsocean: If anything, I think it's possible that as mobile devs we may be scared of the backend because all we know is the front end. I don't think it has to be that complicated/scary. The only thing I'm truly worried about is scaling. Managing AWS resources sounds like an expertise in it's own right, so I need to find a service where it's more automated, same thing with scaling the DB, but I'm sure I'll be able to find these. Anyways, it's going to be hard to feel sorry for devs that repeat the same mistake, and it will happen. Either google will shut down firebase, or one of the crappy alternatives will fold or have performance issues.

Lesson Two: Pick a Solution that Aligns their Product with their Business Goals

@jeffiel: "But seriously developers, trust us next time your needs temporarily overlap our strategic interests. And here's a t-shirt."

n0damage:

Yes, absolutely. Developers have already been fooled twice over the last few years, first by StackMob shutting down and now again by Parse. It would be foolish to jump ship to yet a third proprietary platform and run the same risk all over again.

I understand that app developers want to focus on developing their apps and don't want to worry about building/maintaining/scaling their own backends. But based on these lessons I would not consider a BaaS service that doesn't have:

Full open source access, both client and server.

The ability to run your own server instead of relying on theirs.

Active community development and maturity (can't run the risk of the project being abandoned if the creators lose interest).

These 3 requirements would reduce the risk to a level that I would consider acceptable, much like other open-source infrastructure projects that we commonly use today. To my knowledge there's nothing currently out there that meets these requirements, however.

Oh, and absolutely no infrastructural dependencies on startups. Way too much risk that they'll either 1) straight up die or 2) get acquired and shut down within 5 years.

volaski: i think what the op meant was that it didn't make sense because it's owned by facebook. Heroku being owned by Salesforce makes much more sense because that's their business models are aligned. I remember the first time I was about to try out Parse, fortunately that's around when Parse got acquired by Facebook and I decided not to take a risk. It especially didn't make sense for me because I was going to build a social app. It doesn't make sense to build a social app on a platform owned by a social app company.

exelius:

Parse never made sense to me.

I could see a service like Parse being useful, but it would need to be owned / operated by a nonprofit in order to gain any adoption. Otherwise, it's just another proprietary platform that will get shut off or changed once Facebook (or whoever) pivots to another business model to address that market. There's certainly demand, but I think most developers are wary about putting their company's tech stack at the mercy of a profit-driven company that may abandon them.

In the end though, I just don't think Parse offered enough over existing solutions like AWS and Azure. Both those ecosystems can easily scale from low-end mobile apps (like Parse was designed for) or huge enterprise apps.

Ted Neward: The Parse acquisition was always a weird one, to me. Quite frankly, I couldn’t really figure out what Facebook wanted with Parse in the first place. Facebook is not really a developer-facing company, when you get right down to it...They make money off of people who use Facebook, and buy things from ads displayed in Facebook, and towards that end Facebook certainly wants developers to build applications that make use of Facebook, but Parse really didn’t do any of those things.

You don't want to jump out of the frying pan and into the fire. Avoid another Parse situation by making sure your replacement tools have some sort of viable business model associated with them that at least gives you the hope they'll be around for awhile, though of course no such guarantees are possible. But we can dream.

Alternatives to Parse

There are a surprising number of alternatives: Parse Alternatives, Parse is dead! What are the possible solutions?, 5 best alternatives exist to Parse now that it is shutting down, 10 best alternatives to the Facebook Parse, I use Parse. They’re shutting down. What should I do?, Parse Is Dead: How To Prepare Your Mobile App For That, 15 alternatives to Facebook’s Parse, Could there be an open source equivalent to Parse?, A Summary of Backend Options for HTML5 Mobile Applications, The dirty little secrets of transitioning away from Parse, Top 10 Parse Alternatives For Your Game Backend, Parse just shut down. My app completely relies on Parse, and I have no backend skills. What can I do?, Parse is Gone. Now What?, Here's how to choose substitute to Parse for push notifications

In today's shattered world of nearly infinite platform choices it would be pointless to make yet another list of Parse alternatives. The above lists are perfectly adequate. Parse Alternatives is particularly complete.

But before you consult the lists, since this is a wake, take some time and reflect:

Perform a situational assessment. You are doing that by reading this article.
Perform a status assessment. Think about your product and what you want to do with it. Your answers will have a huge impact on the direction to take. Is your architecture where you want it? Where would you like it to go? Is it even needed anymore?
Perform a damage assessment. What parts of Parse do you use? If you just use push notifications your task will be relatively easy, there are tons of options. If Parse is embedded deeply in your code or you use a lot of services your job will be tougher. List every point of contact your app has with Parse and plan an alternative solution. Ask yourself, how deeply do we want to be integrated with any backend solution in the future? Will the effort and cost be so great to migrate that we just want to keep using Parse as long as possible?
Perform a resources assessment. Do you have the skills, will, money, and other resources to make a move to another platform? If not then you've just narrowed your options greatly. If so then you have a lot of work ahead.
Perform a goals assessment. Do you expect to grow, stay steady, or contract? Do you want to just concentrate on the front-end, like a game, and just get the backend working? Are low startup costs the most important feature of a new solution? Are advanced featurs important to you? Are you just getting started so you are in exploratory mode so the solution isn't that important? Do you just need a cheap solution that can handle a lot of low scale apps with a minimum of cost and complexity? Can the backend be a competitive point of differentiation for your product? Is your current system fast enough, big enough, flexible enough, easy enough to change, reliable enough, cheap enough? Pick a solution that aligns with your goals.

You have a few broad strategy options:

Let it Die

Expect to see a lot of apps wither away as the porting effort turns out not to be worth the effort for non-revenue generating apps. Porting is a lot of work. If your app isn’t successful and the chances of it going anywhere are low, then now is the time to just let it go and move on.

To help you decide if this is the plan for you it may help to read The Parse shutdown and neglected apps by Marco Arment and Allen Pike in the The Joy of Shortcuts.

Migrate to Another BaaS

Parse offered a lot of unique features at attractive price points, perhaps so attractive that it couldn't be profitable, so it’s unlikely you’ll find any one service to completely replace Parse. You’ll most likely have to mix and max services.

You’ll also have to ask yourself: is BaaS a viable business model? Can the company you choose stay alive by charging for its services? Will the BaaS you choose get acquired? Is the BaaS you choose VC funded and if so might that be risky?

Do you believe in BaaS enough to risk using another one? This is all risk management. You can choose a BaaS knowing it might fail because that gets you to market quicker. That's reasonable. Just make contingency plans and keep a clean as separation possible between your code and theirs.

Are you in the beginning stages of a product where the power of a BaaS is the most helpful? Are you entering a product stage where a BaaS is likely to be more costly and lack the flexibility you need to compete? Does your company have the resources and skills to choose a non-BaaS solution? Do you need a good enough solution now or do you have the time to change your architecture?

Answers to these questions will let you know if another BaaS is right for you.

Migrate to a Parse Server

The best alternative to Parse may, oddly enough, be Parse Server, which was created by the folks at Parse. See Migrating an Existing Parse App for more information. The idea is to run your own instance instance of Parse on your server.

Keep in mind Parse did not open source their production API server. They open sourced something that runs the Parse APIs (which incidentally is the beauty of using APIs). It is currently missing a number of tools and features, but that may change in the future.

The bet here is given the year long window Parse is being kept alive that the open source community and Parse engineers will keep improving Parse Server. Over time Parse Server will get more and more feature complete. Parse has already said they are working on adding Push Notifications for iOS and Android and they are considering open sourcing their awesome dashboard as well. Just wait, see how the efforts are progressing, and then jump in if works for you. The point is you have some time to make a decision and a reasonable fallback if all your other options fall through.

The problem is you don’t know to what extent Parse Server can scale. And you have to run the server yourself. So if you don’t want to do the administration for Parse Server or take the risk of Parse Server not scaling as you grow, then this may not be a good option.

If you just need some breathing room to consider your options or you are happy with the status quo then it could work great. If you are starting a new app Parse Server puts Parse back in the mix as a viable backend service.

Migrate to Parse Hosting

Given the release of Parse Server you could have predicted the creation of Parse hosting services. Some options have already popped up: http://yourparse.com/, http://parsehosting.net, http://parse-hosting.oursky.com/. More are no doubt on the way.

The advantage of a hosting service is you don’t have to run the infrastructure, but you do have to pay someone else to do it and it’s unlikely the pricing structure or the capabilities will be the same as Parse.

There are also migration guides listed later for moving your Parse app over to Azure, Google AppEngine, Heroku, AWS, and other services. Something to look into if you’d prefer not to manage your own infrastructure.

Roll Your Own

In this option you reimplement your application so it does not rely on a single service provider. If your app didn’t use a lot Parse services and it didn’t run a lot of traffic this may just involve running a web server and a database. Something easily attainable by developers not skilled in the backend arts. Otherwise this is the most ambitious option and takes the most effort.

Do you have the time, skills and resources necessary to pull this option off? Those are your biggest questions. Do you need to have more control over costs? Do you need more control over reliability, performance, and features? If so then rolling your own is the way to go. The range of implementation options is so huge they are impossible to cover here.

One thing to keep in mind is that Parse Alternatives lists a lot of different services for different functions. Use them. You want to use a service diversification strategy to help manage risk. Don’t put all your eggs in one basket.