Like many other mobile app developers, I was really sad to hear that Parse is shutting down. I use Parse quite heavily for some of my personal projects, and I appreciate how Parse enables mobile-first teams to build apps at lightning speed. They also did a phenomenal job at sunsetting their product. Not only do developers have an entire year to migrate their backend, Parse open-sourced their server so they don’t disrupt any of the popular apps that run on Parse.
As developers look to migrate off Parse to their own infrastructure, we’ve started to field some questions about how Stormpath is different to Parse, and how developers can leverage Stormpath in their apps.
Many developers see Parse as a useful way to prototype and ship an app quickly, but plan to migrate to their own backend as they gain traction, as Parse starts to work against you as you scale. Because of the Parse shutdown, it’s time to evaluate if you should deploy a copy of Parse Server, evaluate another Backend as a Service (BaaS) provider, or migrate your backend off Parse.
Deploying Parse Server might seem like the easiest option for now. Even though it’s a nontrivial amount of work, you can keep your backend up and running without trouble. However, this can cause problems if you’re not careful.
What many people don’t realize is that Parse Server is not Parse’s infrastructure open-sourced. Instead, it’s a “Parse Compatible” server to keep your Parse apps running. In the migration guide, Parse says “there may be subtle differences in how your Cloud Code runs in Parse Server”. As a developer, I’m not excited to find and fix these “subtle differences”.
Deploying Parse Server, while a great stopgap mechanism, doesn’t look like a winning solution in the long term, and really only looks useful for small personal projects or apps in maintenance mode.
While an equivalent isn’t clear just yet, many BaaS providers are already rushing to build migration tools that’ll help you move your application to their service. Even without Parse, other BaaS providers offer a similar value proposition — you’ll be able to build your apps quickly without worrying about the backend.
However, I can’t imagine the transition to be very easy. Just like the edge cases I’m worried about with Parse’s open source server, there will be even more with migrating to another BaaS. Features may not be exactly the same, with some missing and some working in different fashions. As Parse was super feature-rich, I would expect many headaches trying to learn and rewrite your backend for another BaaS provider.
Several entrepreneurs have taken this as an opportunity to build their own Parse-compatible backends, or deploy a hosted version of Parse Server. I’m optimistic about this; I love Parse and would probably use one of these services for my side projects. However, would you want to use this for your business? It’d be difficult to evaluate the trustworthiness of these startups; some of them might shut down less gracefully with Parse, and where would you be then?
For any mobile app with a sizable amount of traction, I think this makes the most sense.
Many developers have already planned to move off Parse as they grow. Now is the right time to evaluate if you should build your own backend. Utilizing a BaaS provider in the long run limits your ability to build an application tailored to your needs, as you start pushing up against the limits of the built-in data models and design patterns, as well as performance issues related to their architecture.
Having made the decision to build your own backend, you’ll now need to figure out your authentication and authorization schemes. Perhaps you’ve decided on a service-oriented architecture, and you’ll need multiple backend services (possibly written in different languages) to access the same user data. Or, you need to move beyond sessions to using tokens so you can have a scalable backend that works across multiple services & platforms.
Writing that boilerplate for your authentication mechanisms takes valuable time which could be used for building actual features in your app. Do you want to spend the time building, deploying, and maintaining yet another service?
Stormpath can help your team write a secure, scalable application without worrying about the nitty gritty details of authentication, authorization, and user security. We have easy SDKs for popular languages and frameworks including Express.js so that adding a authentication for your application can be done in as little as 15 minutes, and can be shared across multiple teams, web applications, and APIs. And if the need arises, your data is still yours and you’ll always be able to migrate off Stormpath.
In summary, Stormpath helps backend developers build better applications faster by dealing with the hard issues of building a rock-solid authentication system. If you’re considering building your own backend now that Parse is closing, I hope you consider Stormpath for your needs.