Why You Shouldn’t Grieve For Parse

by SWIM Team, on Mar 14, 2016 5:07:00 PM

Still looking for a Parse replacement? SWIM is the realtime platform that combines the ease of Parse with enterprise-grade performance.

dead end.jpeg

We all kinda knew this was how Parse would end up.
Parse wasn’t perfect, but they did a lot well. It was easier than the headache of duct-taping your way through a custom backend and nailed the critical experience of easy integrations. Flexible enough to accommodate a wide range of apps, Parse had the SDK’s and user-friendly environment that gave unfamiliar front-end developers the confidence to build their own backend.
But now Parse is gone, leaving many front-end developers searching for the next go-to app platform. Let’s take a look at what Parse accomplished, good and less-than-good, to see what the next generation application platform will need to deliver.

What did Parse do right?

Parse made it simple for app developers to integrate apps with the platform. This is a detail that can’t be overstated. Developers could model their application on Xcode, link up features with Parse and the app basically worked. With an easy-to-understand integration process, Parse unleashed a new class of developers. These “Parse devs” were UI and front end developers that Parse turned into fullstack developers overnight.

Parse also provided a standardized hub to power your entire application ecosystem. Whether they were linking web applications, mobile applications or IoT endpoints communicating with the cloud, developers didn’t have to shoulder the logistical burden anymore. Compared with building a custom database for their app, Parse was a breeze. With Parse’s ease of use and low barrier to entry, it was an ideal solution for bootstrappers and development agencies alike. The price was right, too. You could start your project for free and wouldn’t need to start paying Parse until you crossed their traffic threshold.

Here’s why Parse fell short in production:

Parse’s free tier and quick setup made it an ideal platform for prototyping apps. But when apps built on Parse matured, it forced a decision: start paying Parse and compromise on performance or rebuild the app from scratch with a custom backend. If you wanted your app to be reactive, realtime or responsive at scale, Parse just couldn’t keep up.

This is because Parse required developers t0 pack logic into the client side of an application and coordinate scheduling server-side. The basic rationale was “app developers know how to write client side code, so let them do what they know best” and Parse would do the rest in the cloud. It was a simpler model for developers, but it handicapped Parse when it came to real-time, pulling data, and scaling application performance.

Today’s apps can’t compromise on realtime

Parse touted their ability to give apps 30 requests per second for free (you can still see the awesome graphic on the Way Back Machine). But let’s put that 30 requests per second into perspective. Our privacy extension Privacy Watch scans websites and shows site results in real-time. Privacy Watch regularly makes 300 requests/second or more for each Privacy Watch instance. We accomplish this by distributing application logic in the cloud and continuously streaming results back to the client side with millisecond latency.

Using Parse, we would have had to shoehorn all this processing into the application itself. Site information would have been processed locally, sent to the cloud, buffered and then sent back to the application. Then, the client side of Privacy Watch would have had to request updated information before it was delivered. In other words, using Parse, Privacy Watch would have constantly been loading and updating information, rendering the extension basically unusable.

Scalability is a performance problem

REST APIs create an unnecessary bottleneck for your app data flow.

Parse’s performance issues at scale are well documented (here, here and here). Many developers praised Parse’s performance capabilities, until their app got a surge of downloads and performance tanked. Writing an app that might scale properly with Parse left developers stuck jumping through hoops and troubleshooting their code; the very same problems Parse set out to solve.

Parse marketed their ability to serve push notifications to millions of apps, all for free. But push notifications themselves are extremely limited, especially for REST API-based applications. In order to prompt a push notification, the backend needs to be constantly polling the client application for changes, consuming significant bandwith while it does.

This inefficient process is an evolutionary remnant of the early request-response internet and no longer suits the needs of applications. SWIM’s realtime platform utilizes “continuous push” where changes are streamed to the backend and reactions are streamed back to the client, the entire round trip occurring in milliseconds. Across all our SWIM apps, we’re processing well over 100 million messages a day without compromising on latency.

This may sound complicated, but it’s actually simpler to code. With continuous push, developers no longer have to deal with schedules, timers, buffers and refresh rates. With demand for real-time, reactive applications trending upwards, continuous push will increasingly become a requirement for modern applications.

So what does that mean for the future?

Parse is giving developers until January 28, 2017 to migrate their applications to an alternative solution. As the application market continues to create richer user features that require increased performance capabilities, developers will continue making greater demands of their backends. 
Developers must consider their own realtime and scalability requirements when choosing a platform for their apps. Check out SWIM on GitHub for an easier way to build realtime, stateful applications. Combining the user-friendliness of Parse with performance and reliability usually limited to “big enterprise” solutions, SWIM is aiming to give developers cause to celebrate. 

Topics:SWIM Inc.

Comments