Few weeks after we had started using parse, my colleague wrote a blog post about parse in general. You can read it here.
Just today, one of our developers said: Parse would be a great platform if they would just improve their performances and remove all these limits. The concept is great, the realization not so much. And we are talking about a PREMIUM parse account here.
In this blog post I would like to point out all those limits, and as developers you will probably understand our problems. Basically project was working quite fine while we were building the system. We had quite experienced developers working on the platform (like we always do with new technologies), the code was well organized, and performances were taken into consideration since we already produced lots of apps which expect heavy load. But once we started to do stress testing before delivery, lots of problems occurred, and they were nowhere (or really hard) to be found in the docs:
- 160 API requests per minute for ENTIRE app (not one instance!) (changed to 30+ req/s but it costs quite a lot
- limited number of COUNT operations (differs every time, but surely under 160)
- if you are counting objects with the count higher that just a 1000, the system switches to “approximate count”
- any function can not take longer than 3 seconds
- if that function is in a cloud that time can last 7 seconds
- scheduled jobs can last a maximum of 15 minutes, but you have to put ALL of your code in one function (which basically makes it unreadable for later usages)
- maximum of 2 concurrent jobs (threads)
- no mutex/lock/semaphore logic
- no custom atomic operations (just a few are available, and they are not that useful)
- this makes it very very hard to solve concurrency problems
- log system remembers only 100 last logs
- live logging in the system has a tendency to simply skip a log or two (which makes debugging really funny)
- you can pull a maximum of 1000 objects in a request, which also applies on inner queries
- push notifications have delay (even up to one hour)
- LIMIT SKIP operation can skip a maximum of 10 000 objects
- no DISTINCT operation, you have to implement distinct yourself by parsing data
- lack of incase sensitive string queries, you need to store additional lowercase column in your database
- uptime of parse system is also an issues. Quite a few times, parse was unavailable in general for 30minutes
- no native Paypal integration support, or ability to implement paypals SDK – we had to use separate node.js hosting server to support payments and cash distribution through Paypay
- no debugger when writing cloudcode – you have to rely on logs only, and they have their own issues mentioned above
- no option to delete an entire class from parse via API. image if you wanted to drop logs ?
When you read up on those, and then understand that EACH database request is a separate request (even on a cloud) it is easy to understand our frustration. And no, there is no option to write complex queries and have them executed directly on the database.
As mentioned above, another huge issue are the atomic operations. When parse reaches any of its limits it simply breaks the execution, leaving your transaction opened before everything is executed. There is no execution delay, just a failed request!
Unfortunately, if parse does not improve their system, solving the above issues, it will remain an platform to build super simple apps with not so many users. For real projects with real usages, we will surely switch back to a more performance stronger and stable platform!
If you have any questions about parse, or you think we should add some stuff to the above list, please let us know in the comments section, and I will update the article.
If you are a Parse developer and ended up reading this article, give us a buzz on skype or send us an e-mail, we can provide a more detailed insight into helping you guys improve this great idea 🙂