Ask HN: How was your experience using parse.com? | Hacker News Reader

Ask HN: How was your experience using parse.com?

60 pointsjustplay38 comments

There is lot of fuss going around why to use parse.com, is it really worth it. Assuming my app will have 100 active users, $800/month isn't quite expensive ?

View on HN

The iPhone client was really good and really solid. Unfortunately we had to migrate off of Parse though because of pretty consistent downtime and really slow speeds. It wasn't unlikely for Parse to go down for at least minutes at a time once a day. Migrating off of it is not easy because you have to then replace the really solid client which can take some time to reproduce some of the features you have ended up relying on.

The dashboard also left a lot to be desired. It limits how many tables it shows on the left so you end up having to hack the URL. I believe they finally offered a "fullscreen" mode rather than having a fixed width and height which is nice. Basically we would have to drop down to the Ruby client to audit the data often which isn't the worst.

Parse would also just write random blank rows all the time whenever we did concurrent writes (this is a known bug https://www.parse.com/questions/duplicated-empty-objects-cre...). They have just moved over to the Facebook Developer bug tracking which is pretty awful as well.

Parse was really good to prototype on which was nice, but it is extremely likely if you want to launch anything to the app store and don't want to deal with downtime you have no control over you will need to rewrite it. For this reason I would suggest with just using something home grown.

Hey there, I work on Parse. This is good feedback.

Improving reliability is our #1 priority right now. The bulk of our team is solely focused on it. We've made some good progress and hope to have things in a much better place by the end of the year. You can follow it all on our status page. We try to be very transparent with post mortems and such.

That bug sounds nasty. I'll take a look to see if it's still an issue but I believe it was fixed a while ago.

The Facebook bugs flow has its pros and cons but I believe it's been great for our community on balance. We have an awesome team of folks triaging and repro'ing bugs and interacting with the community thanks to our integration there.

Drop me a note at ilya@parse.com if you have more thoughts about the dashboard or anything else.

So I would recommend using Parse after the end of the year once they figure out their reliability. Infrastructure as a service that is in the process of improving reliability is not very confidence boosting, though.

But I do appreciate that yall have started posting on status.parse.com! That is a major improvement in the right direction.

That's a totally fair assessment.

I just mean to say that we've prioritized it above all else and are really crunching to make it a non-issue for our developers. Our traffic has exploded in the last year so we need to rework some things.

If object goes to MySQL, hire me to scale.

I always think it's admirable when a CEO offers his help in forums.

To address the "moving off of Parse" comment: The way I've dealt with this is to use the Parse REST Client instead of the Parse SDK. That way you're object model isn't tied to parse PFObjects and you can swap out the Networking layer if you choose to move to another vendor. If you control the full stack, you can even model your backend to more-or-less mimic Parse's Rest API.

Yeah in retrospect we should have definitely done this. Although it causes a significant trade off to prototyping speed. I am not sure if its not just worth using your own API at that point.

I have had tons of problems with parse. Our app has both the iOS and website backends using it. While it is useful, and a lot of stuff is well done, when you operate at any kind of scale you keep running into all kinds of hidden limitations. We have ~30k+ weekly actives.

For example - Horrible limitations on queries. You can only get 1000 total objects at any time, batch requests are limited to 50 objects, limit of 100 count requests a minute (not sure the exact number but it's really close). Not just for each client, for your ENTIRE APP.

No good backup solution. They say they back up their servers, but backing up your own data is left to you. Which is a pain in the ass because of point one.

Awful support. I get that they have a lot of people and can't support everyone well, but I have always gotten the feeing that Parse just doesn't care that much about users. Maybe they do if you pay them a bunch of money, but until then you're on your own. Half the time my support requests go unanswered, sometimes the rep just stops responding midway through the conversation. Only recently did I ever have a good experience with Parse support (thanks Christine!)

To top it all off, apparently they silently changed the way batch API requests were counted and never told anyone. Instead of a batch request counting as 1 request, apparently it now counts as each individual object inside the request. So batching 10 objects is one http request but 10 Parse API requests. Sketchy. When you reach over 30 requests per second, they just start dropping requests.

With a 100 active users at any one time? No it's not expensive since over the course of the month you would have hundreds of thousands of users. If you have 100 active users for your app you most likely could use the free/$100 option as it looks like it scales to requests per second which to be at 800 requests per second you would need a LOT of traffic. Highest I've worked with was 500 requests per second on a site handling 250,000 users a day and they only had that at peak times when they got 50% of their traffic in two hours.

I think you would need to look at your http logs to see how many request per second you're currently getting, I highly suspect it'll be nowhere near what you think it is.

Agreed. Our games are played by ~200k players a day and before we added fast-polling for live-play, our peak was around 500 requests/second. That's 65k new games a day and millions of moves - obviously not directly analogous but you get the point.

I looked at parse.com for a colleague and the pricing before you become enormous seemed quite reasonable.

From an Android devs perspective, I will say that the Parse Android SDK is really well made. The API allows for idiomatic, fairly concise, and consistently patterned code. It also adheres to a lot of the coding conventions that android devs are used to like callback functions for asynchronous operations. Set up is super easy too. The offline caching feature is really easy and useful.

That being said, if you have the skill set and time as a developer to be able to implement all of those features and a server/db component, I would. It may not be as robust or clean as the Parse API but hey if its your code it shouldn't be terrible to work with. If you do it yourself, then you get the added benefit of just having to pay for hosting of your server and db.

As some people mentioned, you're over estimating the number of requests per second for the number of users you have. I would recommend writing a small application to get a feel how it feels to develop on the platform.

I personally found it to be incredibly valuable to be only writing client side code. It let me focus on my end users experience and iterate mich faster. After writing an application on parse, I found myself missing it on non parse projects. I used the parse js SDK to create a SPA.

I did think the on boarding experience could be a bit better. The docs are good, not great. I haven't had any issues with down time but my app is probably much smaller. I would definitely use it again.

The downtime is extremely frustrating. They are pretty nonchalant about it as well, which is actually more of a concern than the fact that there was an issue.

Beyond that, there are some good use cases for apps to be built upon Parse and bad ones. It turns out that the thing I'm building is one of those bad use cases.

Parse appears to frown upon background processes. They have very tight restrictions on what can be done in the background and how fast it must be done.

If you have a social-esque app, at any kind of scale, fanning things out becomes a problem.

We're in the middle of packing up our toys and heading over to GAE.

Hey there, sorry to hear you're taking off.

I'd love to hear more about why you think we're nonchalant about downtime. We definitely need to improve reliability and are working hard to do so but also spend a lot of effort on writing up detailed postmortems (e.g. http://status.parse.com/incidents/j336l474l8h4) to be as transparent as possible even if it's painful.

You're right that there are some applications that are a good fit for Parse and others that aren't. We have many social-esque apps that are doing fine so I'd love to hear more. That said, we know it's not "one size fits all" and are working to productize/integrate some Facebook technologies that should make fanning out and other things way better.

Feel free to drop me a note at ilya@parse.com.

I have been prototyping an app on parse over the last month, I've been pretty disappointed. Mainly with regards to their database system. As others have pointed out there's insane limits on things like count queries. There is 1000 record limit on queries in general. The performance of cloudcode between the db is awful, you have to batch everything into tiny operations or risk timeouts. Skip has a 10k record limit. Their web based data browser tool seems unfinished, for instance you can't even insert into relational columns and deleting 100 records at a time locks up my browser.

This guy has compiled a good list of limitations: http://profi.co/all-the-limits-of-parse/

It may be okay for very simple applications but for anything non trivial or with a large db I would not recommend it. Any time saved by having a PAAS out of the box is lost trying to work around all the weird data access limitations.

I'm wrapping up an iOS project using Parse and wrote a Core Data <-> Parse "offline mode" / sync engine for it. From a development perspective I'd say it's relatively painless.

I did encounter a "bug" wherein certain queries can't be cached effectively which I solved by using vanilla arrays instead of Parse's PFRelation. No downsides to doing it that way (for this project) but it felt awkward. It would be better to have more consistent caching behavior.

I encountered other issues but that one is top of mind at the moment.

I have seen downtime during development. It's usually short-lived but it's there nevertheless.

Parse gets you up and running crazy fast. So it's extremely useful in that way. If you're making a mobile app the speed the SDK gives you in working with a pre-built backend cannot be underestimated.

Recently I started a project with Parse but eventually moved off it ( with some pain ). The pain points for me were random requests timing out or randomly taking 20+ seconds to respond. Also the SDK wasn't as flexible as I needed it to be ( which is typically the case with any ORM ). The forums/support isn't great so if you run into a showstopper, you're pretty much on your own.

I tried out their PHP SDK, intentionally willing to try out Parse on the backend side of things. I intended to use it as an ORM layer, abstracting out the data structures. However, my experience was that making multiple queries (even 3-4) would make the app appear slow. This is in no way a fault of Parse, just how it is.

So, I'd recommend using Parse with any of the frontend SDKs (JS/Android/iOS), but would warn you against trying it on the backend side of things (where PHP is the only offering so far).

I have been using Parse for a couple of years now. Some of my clients are currently on it and is being used in production. The most compelling part of the offering is a well thought out SDK which helps in time to market by reducing the development time. Parse has a lot of potential but unfortunately they will need improve in some areas pretty soon. The first issue is documentation, it is bad. What makes it worse is not being able to build a large enough developer community around the product. If Parse would only listen to the developers using their platform, take constructive feedback and improve their offering it will go long way. The response from Parse when things are bought to attention is much to be desired. Part of the problem is Parse needs to solve is to partner with companies/developers to help out their customers with the common issues that people face when using their platform and concentrate on the real issues of the platform. This should also help them with their support as well, which is bad even for paying customers. I really think Parse can learn from companies before them like Microsoft, Salesforce, Apple on how to go about building a strong developer community around a platform. I also think Parse can help a wider range of customers, like make a serious play in the enterprise market if these issues are looked into.

I can't comment on anything but the Push notification service, but we've been super impressed; it's so much easier having our backend just call the Parse REST API and have our iOS clients register PFInstallation objects and assign themselves to channels than it was to setup enduring TLS sessions to APNS on App Engine.

I did mobile contract work for 2 years and built most of my products on Parse.

The free tier goes a long way. In my experience, if you are thoughtful with the quantity of requests you send from the clients, it will take over 1000 users to push you into the paid tier. This really depends on the nature of your application though.

As for development, there are a few nuances that you have to get right to use Parse at full capacity. First, delegate as many operations to CloudCode as you can. I do this for separation of concerns (clients should focus on displaying data, not retrieving and formatting it) and more importantly, to make cross platform applications consistent and easier to write. Also, you can change behavior on the fly instead of creating new builds of your client when you just want to change a small detail, like the number of results to return. When using CloudCode, take advantage of Parss's implementation of JavaScript promises. And avoid mixing promises with the "backbone-like" callbacks. There's a bug I've found when mixing the two that will occasionally cause the operation to finish before executing all the callbacks.

And speaking of bugs- the biggest drawback of Parse is the documentation and support. Some entries in the docs will actually be a one sentence reiteration of the title of a method. It's mind blowing how shitty some parts of the docs are. The support is even worse. Looking through the help archives (they've now given up on internal support and moved their entire support platform to stack overflow) you will frequently find smug answers from the Parse team. It's common to see a Parse support teams response get tens of downvotes. It's bad. I once found a bug in Parse's method to save multiple objects at once (if the first request failed, all subsequent requests would fail too) and getting a fix implemented was a huge pain. I had to go through Facebooks bureaucratic big reporting process only to be told the bug was a 'feature' weeks later. I resubmitted the bug with all kinds of proof and demo projects, and finally after a few months I got the email saying the big was fixed. Huge pain.

Overall, if a prototype backend will suit your needs, I highly recommend Parse. It's certainly not the pie in the sky it could've been, but it gets the job done and lets you quickly get to market.

The free push notifications, data dashboard, and analytics are some nice sugar on top too.

I will probably continue to build my products on Parse, unless I know I will need immediate scale, or a client requests a specific backend configuration.

Been wanting to try Firebase too. It's a Parse like BaaS where everything is done in realtime. Very cool, but still somewhat unproven and new. Has anyone used Firebase?

These are exactly the same feelings I've had, glad I'm not the only one who saw those answers as smug...

Agreed, 100%, about the tone of the "community advocates" parse has answering questions and supporting the forums (their internal + s/o). Huge turn off.

If you could direct some improvements to our docs, where would they be?

I'm in the process of helping a client migrate a large data set (5m users) off parse due to the issues they've had. They had a fairly consistent rate of 1 in 100 requests return a ECONNRESET error in node. After over a year of haggling with the parse support team the errors finally disappeared about a month ago. They needed at least 10 fetches so you can imagine that 1 in 100 not returning doesn't bode well.

I don't have all of the specifics as to how or why the errors went away, but no changes in the client's codebase were made that relate to this.

Summary: seems brittle, tech support was useless, customer wrote huge checks to parse every month and didn't get traction fixing the problem. Even though things have improved we're continuing with the effort to help migrate the client away from parse.

The new pricing is very good, and you shouldn't need to pay until you're running a lot of traffic.

I find the iOS SDK to be pretty solid. Push notifications also work really well.

I have also noticed requests fail from time to time , but it hasn't been too much of an issue.

What I don't like is the query system. What would be trivial in SQL is sometimes difficult or impossible.

I also just don't like that cloud code queries are all asynchronous. Promises help, but complex operations end up as a huge nest of promises. I just have no need for server-side code to be asynchronous.

The console has been slightly improved, but the data browser is still a bit painful. They like to break the back button quite a bit too.

I have one large app using Parse as a back-end, but otherwise I just use it for push.

Aside from the price there seems to be a few bugs that have been lingering around for a year or longer with no fix in sight.

One that I have encountered is when uploading files, the progress callback jumps from 0% to 100%. https://www.parse.com/questions/parsefile-progresscallback

The annoying thing is the documentation states: "It's easy to get the progress of both uploads and downloads using ParseFile by passing a ProgressCallback to saveInBackground and getDataInBackground." and provides a code snippet that doesn't work and hasn't worked for two years. Please fix the bug or change the documentation!

Our experience with Parse has been absolutely terrible. A couple weeks ago, their servers went offline for hours in the middle of the day. When they came back up, all of the relation columns in an entire production database for one of our client's apps were magically deleted. This created a myriad of issues that we had to painstakingly traverse. To make it even worse, they have no true concept of backup and restore. Sure, you can backup and restore regular data columns and pointers, but there is no way to restore relational data through their data browser. Go ahead, try, it just errors.

If that's not enough, they constantly change the way things work on the back end. Is your app working perfectly this week? Great, it won't be next week. All of the sudden you could no longer check if an object was equal to [NSNull null] - the way I'd seen as a recommendation on their own forums multiple times, and something that was working perfectly until one day, it simply stopped working without any client or cloud code changes. This caused queries in a production app to suddenly start returning wrong data, and chaos followed.

As far as support, it has been a joke. We have reported showstopper bugs multiple times, and every time we are met with rude responses, followed by NO ONE addressing the issue for weeks, then the issue magically gets closed. I'm sorry, but if you can't backup or restore data on their platform, they probably shouldn't be spending so much time redoing your website every other week. It'd be nice if they'd fix mission critical features instead.

Lastly, the downtime and limitations. They go down literally 10 times a day for short periods. If you're an active developer, you've definitely noticed this. The least they could do is acknowledge the regular service interruptions on their status page, and have some accountability for the slowness. We will be developing a data migration tool for people who want to escape this terrible platform, and the tool will allow for migration of their data to a MySQL setup. In the time we've wasted trying to work around their countless limitations, we could have build complete custom REST APIs for our clients.

My experience has been quite good with Parse. We have push notifications service for iOS and Android and both of them work as intended. Though, I feel the dashboard could be better.

I tested it for a tiny project and was very surprised. It's very easy to use, though I wouldn't use it in production because of the price / lack of customizability.

Same as what everybody else is saying. Solid SDK, but downtime is a major issue. Worse, some partial downtime scenarios or bugs get next to no attention for days. It may not be a "site down" situation, but it may be critical for your app. And yes, documentation is extremely sparse, with few real world examples if any.

From what I've read in this thread, Parse isn't that good for production, but there isn't anything better, is that correct? If not, what are good alternatives to it?

it is easy to use, but quite expensive. my debugging activities could use up 10% of the free capacity.

I thought I wouldn't afford it, so I moved away.

it's easy for prototyping, but impractical for individual developer.

Great for prototyping, but I wouldn't bet my business on it.

Eh. Parse had some downtime over the summer that was pretty bad. I'd recommend going another direction.

That is expensive.

Hi, If you want to create API, why dont you use onlinewebapi.com It is still in beta stage but looks promising Disclaimer: I am founder of this product. Feedback would be valuable. :)

Reply on news.ycombinator.com