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.
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 email@example.com if you have more thoughts about the dashboard or anything else.
But I do appreciate that yall have started posting on status.parse.com! That is a major improvement in the right direction.
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.
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.
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.
I looked at parse.com for a colleague and the pricing before you become enormous seemed quite reasonable.
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.
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.
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.
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 firstname.lastname@example.org.
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 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.
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.
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).
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.
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?
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.
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.
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!
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.
I thought I wouldn't afford it, so I moved away.
it's easy for prototyping, but impractical for individual developer.