Why you shouldn’t be upset if you built with Parse.
A small big earthquake today shocked the developer community with the announcement of Facebook shutting down Parse.
The news came out of the blue and went trending on Twitter very quickly with a good amount of overreaction. I understand the surprise-effect but even if this hurts, Parse is providing a lot of support to developers who have built on top of their service. The service will be terminated January 28th 2017 and the whole platform has been made available on Github.
Users reaction ranged from panic, to kudos, to backend providers spamming their service (of course). If you built your app with Parse and you’re wondering if you should be upset if you took the time to build with it, my answer is no. And the reason why is that you probably wouldn’t be able to ship your product in time (or ship it at all) without it.
A comment on the Hacker News thread regarding the announcement said: 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.
I really think it should be considered the huge number of services that you rely everyday that would cause similar damage if they were shuttered.
Despite Parse’s shutdown BaaS has a bright future.
New mobile and front-end developers seem to have huge preferences for back-end solutions. If you’re making a mobile app, the ease and simplicity of not having to deal with creating a backend at all can be a huge asset to hit the ground running fast.
The demand for software development is dramatically outpacing the supply and being an expert on every single bit of the complex infrastructure that power apps today is really hard.
At the end of the day, very few products have the real need to control the whole stack so you shouldn’t even be worried in migrating to another BaaS. Tons of tools will be published over the next weeks to help with the migration so your product is not in danger, neither your business. No need to freak out.
One way to solve this problem is to migrate your backend to a self hosted instance of Parse. The second one is to migrate to another BaaS.
The upside in the first scenario is that your client side remains as it is, and you don’t have to refactor the whole app to unplug the Parse SDK. The downside is that the migration process is non-trivial and you need to train your development team to maintain and scale the service. Lastly you will end up maintaining two codebases as you would be in charge for both the backend and the front-end and I would be worried of potential future developments that you might have to face in the future.
Cost of ownership of a piece of software (aka maintain it over the time and scale it) is way different from the cost of purchase (setup your own self hosted Parse server).
Lastly consider that “some of the more important pieces of Parse would still be missing like their WebUI”.
The second scenario is about finding an alternative BaaS to Parse that covers all the features that you’ve been using for your app. Considering how for how long back-end service providers went head-to-head, most of them present a very similar set of features.
As a founder working very close to this space I track a lot these services and I would recommend to quickly navigate this list and see what fits better your needs.
If you’ve built a native mobile app along with Parse’s major features such as push notifications, user management, roles and cloud code I would check out: AWS Mobile Hub, Backendless or Syncano. For those of you with more enterprise-grade requirements Kinvey, Kony, Anypresence, or MoBack are probably the right fit.
If you’ve built an app that relies on Javascript and was fully hosted on Parse then Stamplay, Firebase, Syncano or BackAnd are viable options.
We’re shifting towards an era of software as building blocks and I believe that BaaS like Parse are only the tip of the iceberg.
Not too long ago, many would look at those using AWS or Heroku instead of working on bare metal and running their own servers with the same attitude as those using Parse today: “that’s too risky, you’re better off doing it yourself”. But, as we’ve seen, that’s really no longer the case. Infrastructure can be sold as a service, and I see no reason the same can’t apply to your whole backend.
This is even more relevant when you think at all the third party services that you use when you build your apps. The real need of developers is becoming more and more orchestrating services and building on top of the existing API infrastructure available. BaaS are super convenient until you have a use case that goes beyond the built-in capabilities.
Perhaps you want to replace the default push notifications component with Urban Airship (a highly specialized, top-of-the-line push notification vendor). Maybe you decide you want the highly advanced analytics capabilities of Mixpanel to replace the ones that came with your BaaS. Another option is Engagement Automations like StreetHawk that give you simple push but also deeplinks, segmentation and triggered push that marketers or product managers can easily use. As companies build up their mobile competence, they will increasingly want and should be able to do that.
Time will tell how the future looks like for BaaS. But the way we build software has changed a lot over the last 10 years, it got simpler and it will keep going that direction. Once again big kudos to Ilya Sukhar and the team for what they’ve done and how they influenced the whole industry.
So keep calm, code, and enjoy the show.
