Hacker News Reader

Comment by xoail | Hacker News Reader

Parse is indeed taking up the mobile-backend services by storm. As much as I love to use parse, I don't see why any serious app would stick with them. They are good to get started but eventually I feel apps will move away into their own backend infrastructure since it is not hard to implement and allows more flexibility and control. Glancing over parse's client portfolio I could hardly recognize 3 apps that are average popular.

EDIT: Please don't get me wrong. My proposition was in terms of how many serious apps will adopt Parse. I currently use parse for 3 of my apps and love it. But I am a free user and never bother paying for their service coz there is no need for it.

View on HN

1) You aren't looking hard enough, go look through their app gallery. For my part, I've deployed Parse in Gaia GPS, StopWatch+, Shark Net, and it's saved me mountains of time. Gaia GPS is the highest grossing hiking app on the App Store, and Shark Net was downloaded a bazillion times as part of Shark Week.

2) Why would developers stick with Parse? Well, because the price is just negligible for what you get - there will never be a good ROI to switch away. You can use Parse at the Pro level for literally years, and it doesn't cost as much as a week of effort from an A-level developer.

Parse = $4800 for two years

Awesome Developer = easily $6000 for a week of work

3) I love Parse for how easy it is to whip up server-side stuff, where I'd like some flexibility in how it's implemented. Before, I would write features and have to ship new versions if I wanted to make a change. Now when it occurs to me to make something server-configurable, I don't heistate to use Parse - it just doesn't add any time over using strictly client-side stuff. And the web interface makes it simple to "admin" and tweak the features.

Don't even get me started on how easy Parse makes it to do Push notifications and how well that works.

We have some very serious brands on board including Home Depot, Armani, Food Network, Green Bay Packers, Discovery Channel, Cadillac, and more. The folks building these apps don't want to be working on caching policies. They want to make beautiful, engaging applications. They stick with us because it's just easier.

I can completely understand the decision to use Parse. On the flip side of what the parent commented, big players who only have a comparatively limited presence in the mobile world don't always want to have to hire a full team just to implement their one or two simple apps. Conversely, a small player might not have the resources to hire a full team, or might not have the know-how or time to implement it themselves.

A team that is deeply invested in mobile might want to engineer their own solution. If you're a mobile-only company or even a mobile-first company, I would expect you to have a full backend team. Otherwise, contracting out the bit you don't have resources for just makes sense. That's where I see Parse sitting in the world, and with the client list you mentioned, it seems to fit perfectly. I wouldn't expect Home Depot to have a complete mobile team.

I'm not so sure about this.

I'm writing a pretty complicated application using parse. It's been great so far. I've been a very vocal non-fan of their iOS SDK though, so much so that I'm actually dropping it in favor of a custom written job using their REST API instead. But besides that one thing, it's been fantastic.

The new Cloud code stuff they just added is awesome.

I spent 10 years doing heavy backend shit until about 5 years ago when I switched back to native front-end development. I still am having to write a service here or there to cover some holes that Parse doesn't cover for this application, but those are pretty small holes.

A+++ would use again.

As a (paying) customer of Parse, and someone who really like their iOS SDK - what is it that you don't like? Is it that the stuff you're trying to do doesn't play well with the way the SDK is architected, or is a more general dislike of the approach (compared with, say, the rather more structured incremental-store based SDK that StackMob use)?

I don't like that subclassing generally doesn't work. You can subclass PFObject no problem, but you lose it when you are doing a lot of PFQuery'ing. PFUser would be a prime candidate for subclassing but that really doesn't work without a lot of shim'ing.

I don't like the lack of client side persistence. There is caching with PFQuery but it's caching the json response from the server. For example, let's say I have a message board with 1000 messages. If the user posts a message, I can't simply add the new post and have it cached, I would have to query and pull down all 1001 messages.

Now, I've written all the boilerplate around the parse SDK to do all of this, but it was kind of hacky. So now I'm ripping it all out and just using the REST API with my own custom digs. Much smoother. I'm slowly moving it over to it's own static lib at: https://github.com/jawngee/CloudObject

Don't get me wrong though, their SDK is definitely usable, but after a certain point it becomes a little cumbersome.

PFObject subclassing and a more comprehensive offline solution are both very high on our list of features we would like to add. We're just taking our time to make sure we get them right. :)

Parse should offer a dedicated enterprise solution to run their stack (as source code) and warehouse your data on your own servers (or own AWS account). That would offer a real migration path for apps that anticipate reach critical mass in their user base.

Reply on news.ycombinator.com