I have inherited an application based on parse a few weeks ago, I can share my experience with platform so far.
Documentation
There is a lot of documentation, thats good. It can be hard to understand what parse is capable of, since features can only be available in one SDK and not the other. Since there is no “general sdk client” guide I have basically jump through all client SKD documents to understand what is described.
Example from the docs:
“To make it super easy to create user-private ACLs for every object, we have a way to set a default ACL that will be used for every new object you create:”
- js/guide/#access-control-lists → // not available in the JavaScript SDK
- /rest/guide/#object-level-access-control → // REST client: code snippet not even rendered, you will be confused if you read this the first time
- /unity/guide/#object-level-access-control → // // not available in the .NET SDK
for the parse server you also need to check with two sources, since not all info is available in one or the other:
- githubcom/parse-community/parse-server
- parse-server/guide/
Authentication & identity
There are many adapters for identity providers, however the we need to implement multiple identity platforms for different tenants. We struggle to understand how the authentication flow is supposed to be with an custom authentication provider. There is a little bit of information on many places:
- /parse-server/guide/#custom-authentication → server side
- /js/guide/#linking-users → js client side
- check the jasmine test case
- check the source code
Every section explains a little bit, but there is no clear high level picture how the flow should be and it is a lot of trial and error to understand the code flow. If you search google and the forum that questions are asked repeatedly about how sessionTokens are supposed to work, how “linkWith()” is supposed to be used.
Security
Everything is allowed and enabled be by default. This is good for development purposed, but poor from a security standpoint. Since by default everything is allowed you have to be extra careful about locking down your app, not slipping config errors to production and creates a attack vector. I suggest when you start developing lock everything down / deny all from the start and enable it when you you need it, since deny all will create much less opportunity for security holes.
Client centric view
The documentation is written around the idea that all business logic is centered in the client. I need to support features to multiple clients (mobile, web, REST) which means I have to duplicate the business logic “e.g. list all active users” multiple times within each client. Currently I have to evaluate if I can migrate the code from the clients to Cloud Code functions.
Market outlook
Parse has an active community and at least one business offering commercial support. On a market view every big cloud vendor invests in its mobile dev framework (AWS amplify, Google firebase, MongoDB realm/stitch, Azure Mobile Apps). Each vendor has their own issues and you get the benefit of highly integrated services, with a steep learning curve. Open source projects with no vendor support struggle about continous support, e.g. lasts year when the core maintainer of hapijs quitted and the future path of that project was unclear.
Note: Had to remove links because “Sorry, new users can only put 2 links in a post.”