Parse Server lacks depth, DreamFactory digs much deeper

parse.png

Parse had some initial success among native game designers. If you were writing an iOS or Android app and you weren't quite sure how to code OAuth or Push Notifications, then Parse was an easy fix for the problem. They also provided help with User Management and a place to store the information on your High Scores Screen.



Unfortunately this audience didn't have much money, and Parse didn't have the features that an enterprise customer would need, and so Facebook decided to shut the company down and "open source" what was left. Better late than never I suppose, DreamFactory was Apache License from day one. At any rate, I've had a few people ask me about the differences between Parse Server and DreamFactory, so we whipped up these comparison tables.

Features Parse Server DreamFactory
Active Directory Support  
Email Templates  
Call External Services
Web Based Admin Console  
System Services  
CORS Support
Role Based Access Control
Application Migration  
Interactive Documentation  
Application Hosting  
Multiple Applications  
Push Notification Support  
Server Side Scripting  
Building Custom Services  
SOAP and REST Translation  
XML Support  
Combining Multiple Databases  
User Management
Geopoint Support  
SDK / Sample Apps
Open Registration
API Management *  
API Analytics *  
Multi-tennant Hosting *  

*DreamFactory Enterprise

Data Sources Parse Server DreamFactory
SQL Support
MariaDB  
MySQL  
SQL Server  
PostgreSQL  
Oracle  
DB2  
NoSQL Support
Salesforce  
CouchDB  
Azure Tables  
Cloudant  
MongoDB
DynamoDB  
File Storage Support
Local Storage
Amazon S3  
OpenStack Object Store  
Rackspace Cloud Files  
OAuth Support
Facebook
GitHub  
Google    ✓
Twitter  
Email Support
Amazon SES  
SendGrid  
Local Email  
Mailgun
Mandrill
SMTP  

There are some big differences hidden by single lines in the tables above. The new Parse Server doesn't have a web based administration console. This will make it very hard to configure. There is no interactive documentation, but I guess that is OK because they don't have that many services, either. They only support one backend data source, with zero support for SQL, which we consider to be the primary enterprise use case. They don't have support for server side scripting or custom services, another major gap.

So taken all together, you can see why Facebook gave up on this. The SaaS model didn't work for enterprise customers, and the product was falling farther behind every year. You would be better off starting from scratch. Or, better yet, install the world's best REST API Platform today and spend your time building a real application on an enterprise-ready stack.