
Ask HN: How was your experience using parse.com? - justplay
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&#x2F;month isn&#x27;t quite expensive ?
======
imownbey
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...](https://www.parse.com/questions/duplicated-empty-objects-created-by-
concurrent-saves)). 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.

~~~
csmajorfive
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.

~~~
imownbey
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.

~~~
csmajorfive
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.

~~~
themonk
If object goes to MySQL, hire me to scale.

------
SurfScore
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.

------
johnnyfaehell
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.

~~~
themartorana
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.

------
sourdesi
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.

------
wasd
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.

------
MrMike
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.

~~~
csmajorfive
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](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.

------
Element_
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/](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.

------
mbenjaminsmith
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.

------
solomone
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.

------
captn3m0
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).

------
vesh
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.

------
kixa
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.

------
fyobidniss
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?

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

------
eastridge
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.

------
fleeno
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.

------
infinite_snoop
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](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!

------
teepis
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.

------
mundanevoice
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.

------
LazerBear
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.

------
mbtmbt
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.

------
dcarmo
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?

------
billconan
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.

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

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

------
fooaway
That is expensive.

------
alekh88
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. :)

