The way everyone seems to use it, in my experience, is giving the client credentials to manipulate the full database which is absolutely insane. Obviously this is not good practice but every single parse project I've gotten thrown into already did this and it was a significant amount of work to move it to be more secure and NOT do that. I think the way it's created makes it very, very easy to make bad security choices.
It's also basically a RESTful CRUD. That's mostly it minus some, mostly minor, bells and whistles. You can already do this with about 20 different open source stacks very easily and you're not stuck using this parse technology.
I can't articulate just how much trouble parse has given me. I even took an app and re-wrote its entire backend away from parse significantly faster than doing a handful of updates.
I can sympathize with this. I work on a dynamic API security scanner, and the vast majority of the Parse APIs I've scanned have either used API keys with full read/write permissions on the DB, or have left the database in development mode, essentially allowing anyone with an API key to modify the schema of the database.
Parse was a very cool product, but most setups I've seen didn't take advantage of the (sometimes hard to find) security features Parse provides.
Not to disagree with your overall assessment. I'm generally wary of these swiss-knife frameworks - they're written for a particular use case in mind, and if your project doesn't fit that, you may go through contortions to get things working smoothly.
That's fantastic! I never kept track of which version(s) I worked on but I had transitioned one project from Parse to Parse Server and it was still able to work this way but I'm glad they made progress to try and force better security.
So instead of making HTTP calls to directly modify the DB you make HTTP calls to cloud code functions you wrote which then verify who you are and only modify what you should be able to modify.
The open source project is great and I appreciate the effort that went into making sure we didn't all get (totally) screwed.
Would I use Parse-Server for a new project? Probably not. The state of the BaaS options out there has changed/improved significantly since Parse.com was a thing.
Happy to answer any questions, or get some current devs there into the conversation to help out.
Take a look at this video and tell me this query and the required data denormalization is acceptable.
Something as simple as filtering by 2 or more values becomes ridiculously tedious.
http://stackoverflow.com/questions/26700924/query-based-on-m...
Also since Firebase doesn't allow more than one filtering field with orderByChild(...) I'm guessing Querybase will do all the work on the client. This is less than ideal since the data has to be downloaded first.
Here's a practical example of doing joins with Firebase (written by David East who is also the star of that video you linked): https://github.com/davideast/Querybase
https://medium.com/@Pier/firebase-the-great-the-meh-and-the-...
Don't get me wrong, Firebase has a lot of good things going on, but the bad aspects make it unsuitable for a large variety of projects.
As I found out today if you want the analytics data in CSV, or query it to any level that's useful beyond "We have 5 users in Stockholm on KitKat", you'll need the next service tier up, which is $25 per month per project.
But if you want basic analytics, then it's free & easy.