During this year-long shutdown/migration process, the open-source and community maintained Parse Server is what most people switched to. Parse is yours now. https://github.com/ParsePlatform/parse-server
IIRC the Parse homepage used to have this, but ever since the shutdown notice (so, for the past year) the homepage has largely been useless.
Attracting new users unfamiliar with the technology seems at best secondary ( and possibly, unwelcome) to the Parse Server community now.
That said, I never used it, I saw it appear, had a look, decided what it offered was too rudimentary to be scalable, and moved on.
That said, as an open source offering, it's quite interesting.
This post answers the basic question, what is parse:
I'm still unclear. It's some sort of hosted database+services?
From my reading it seems like a generic rest service. I suppose like COTS for rest services.
perhaps this http://rawrmaan.com/why-parse-failed/ might be a better explanation ?
This is a major failing of a lot of open-source projects and a lot of real companies as well. Fortunately Wikipedia often provides some background. It's my go-to place whenever I'm confronted with some un-navigable home page filled with hipster jargon about how a company wants to "empower" me with "cloud" "solutions".
Here's a brief history of Parse: https://en.wikipedia.org/wiki/Parse_(company)
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.
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
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.
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.
Happy to answer any questions, or get some current devs there into the conversation to help out.
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.
You guys are aweosme!
As a shameless plug though, there are other Open Source alternatives though - we wrote a migration guide for ours: https://github.com/amark/gun/wiki/Migrating-from-Parse .
See inside /bin/parse-server:
require("../lib/cli/parse-server");
However there is no /lib folder, apparently its name is /src. So there is basically no possible way that is even able to run. How is this possible? Either someone linked /src to /lib (doesn't make sense) or they changed the name of the folder and didn't change anything else.
https://github.com/ParsePlatform/parse-server/blob/master/pa...