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
I would call Parse a "Backend as a Service"[0], akin to Firebase[1]. "API as a Service" is more like Apiary (bought by Oracle) or Apigee (bought by Google).
The first iOS app I built used parse for the entire backend. We basically used it as a database in the cloud accessible by multiple clients (it can accommodate fancier uses as well). We didn't really run any custom code on the server side, Parse basically provided access to a shared db across our client instances. It allowed us to build a simple location sharing app in a few hours.
From my understanding, it provided services that you would have to create from scratch in your own infrastructure that would be a significant undertaking. For instance, push notification in iOS is a bit of a nuisance if your app really doesn't rely on a complex server back end, but you would like to still add push notifications. Parse did this portion for you, so you could focus on the product. I could be wrong though, I looked at it a year ago, and my memory isn't what it used to be.
It was basically a CRUD API as a service; simple object storage and retrieval via HTTP, with goodies like validation and nested routes (joins) and such built in.
And if I download the open source code, and run it on my own server, is it a service as a service as whatever-the-opposite-of-a-service is? I'm confused...
You're thinking too small. Support it multi-tenant on a fleet of servers and sell it to customers, now you've got a service-as-a-service-as-a-platform.
Huh. Yeah, I dove around a bit, browsed the wiki, etc, and so far all I've seen is the equivalent of "an open source version of the Parse backend". No description anywhere that I can see about what it does or why you should care (unless you're already on Parse, of course).
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.
So many posts on HN are like this, assuming that every obscure webservice is common knowledge. "Jabberwocky has reached version 1.1! Performance increased by 30%, users must migrate from 1.0 by the 12th. Use Jabberwocky in your business now! New users get a free trial!" OK that's nice but what tf is it and why should I care?
Yesterday I built a 100M user social network using Jabberwocky. It took me just 25 minutes, bro, and now I've retired to my own private Caribbean island.
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".
I'd assume the main goal of the open-source Parse Server is to provide some support for previous users of Parse? Who would already know what Parse does.
Attracting new users unfamiliar with the technology seems at best secondary ( and possibly, unwelcome) to the Parse Server community now.
Parse.com was a BaaS(backend as a Service) acquired by Facebook in 2013. Using the platform was possible to build and host most of all your app backend(database, legacy code, integrations, Push notifications, send emails, social login, ...) and to integrate with your app front-end using the SDKs or even using a REST API. Parse Server is the open source version of Parse.com launched after the Parse shutdown announcement.
Something I've been wondering is would you recommend using the open source Parse server for new code or is it more targeted towards projects that were already using the Parse API?
It's geared towards legacy. I have used parse in 3 different projects (none of that was my choice, these were existing projects I had to take over) and I would NEVER recommend it for new projects.
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 think the way it's created makes it very, very easy to make bad security choices.
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.
Later versions don't let you easily give the client full access. You instead have to do it through Cloud Code (another facet of Parse), so the key never leaves the server.
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.
> Later versions don't let you easily give the client full access. You instead have to do it through Cloud Code (another facet of Parse), so the key never leaves the server.
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.
I just noticed the app I used with parse did exactly what you said (gave the client full access to database writes). My app only held "public" data and no passwords, emails, or sensitive data, but I was wondering how you manage to secure the DB writes. Wouldn't you need another server to send the write requests that would validate them before sending them to parse? Or is there another way?
To secure code with parse I believe the most common way is to basically move everything behind cloud code.
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.
I have created a few apps using Parse.com, one of them successful enough to take the additional time/cost hit to migrate and host myself using the Parse-Server project.
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.
I used to work at Kinvey, they've got a pretty good product geared towards integrating with whatever you've got to connect with. They have always been security conscious, even have HIPAA support now IIRC.
Happy to answer any questions, or get some current devs there into the conversation to help out.
I second the Firebase recommendation. Facebook killed off their BaaS acquisition while Google doubled down on theirs. If you prefer open-source, Horizon (http://horizon.io/) is a great alternative to Firebase but does not have many of the key features like file storage and iOS/Android SDKs.
I wouldn't call this an "issue" as much as a "limitation". Just as you can develop a data denormalization process for any use case, you can develop one for Firebase.
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.
Horizon is a scary recommendation right now given the recent shuttering of RethinkDB (the company). It might still be a great choice, but I would give the community some time to coalesce and see where things end up before recommending it for new projects.
I really like Firebase, but for specialized cases as others mentioned. The realtime updates are solid, and the iOS SDK at least is deep enough to let you dig into edge cases when needed (like, how many clients are listening to this node?). But I use it like an in-memory store to sync live data. Can't imagine having to use it like a full database - I use Parse for storing more permanent data across tables.
Yes it's google behind ... but you should rewrite the whole application. That's why I respect Facebook about their decision to opensource the Parse Server. The is the beginning of the Open Backend world. With Parse Open Source everybody will get Personal MBaaS :)
I think it depends on your level of expertise and the requirements of your project. Having Parse Server as something you can set up in a few minutes on a VPS and start building a client-server app is great. The integration via the various SDKs is incredible, and it takes a long time to build something like that out. All the available options have their tradeoffs, but I think having the source and an interested community is a great pro in the Parse column.
I used it for a new project I started 6 months ago. We've since transferred to AWS and a Express/Node.js project. However the Parse Server open source project is very well maintained and supported. I would recommend it for any quick prototype project you need a backend, but don't need it to do anything fancy.
for mvp I would say yes, parse-server provides security (ACLs/permissions) and performant database query helpers out of the box, its a battle-tested abstraction layer to mongodb, I had to make some workarounds to work for my specific usecase but just like any other framework it has it pros and cons, marketing and getting new users is the bottleneck for me not the database
Awesome Fosco! The open source community has already 12k+ stars on Github and is growing fast. Thank you for all the work and collaboration! You rock guys!!!!
I second the sentiment that Parse has done a good job of shutting the platform down and giving users warning/notice. I hope the Open Source version takes off (looks like it has, with 12K stars!).
The same with the package.json, it points to /lib/index.js.
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.