Parse.com vs Parse Server
Thanks to the forthcoming shutdown of the Parse server in January 2017 many developers wonder how they will keep their applications online from now on. This article focuses on the solution provided by Parse: the Parse-Server project. This is an open-source version of the Parse code, but with a few key differences.
To protect their data It’s extremely important for developers to migrate their apps to others solutions, such as Back4App .
For comparison purposes we analyzed the following factors:
- Ease of deployment
- Management interface
- Syntax Changes
Ease of deployment
Let’s start by looking at how easy it is to deploy an app. The solution provided by Parse.com is much simpler as it allows anyone to create an app with just a click of a button. The Parse-server deployment is far more complicated. You must first of all manually configure your parse-server and your DB server and afterwards host these two servers in a PaaS or IaaS (like Heroku or AWS) to finish the deploy. In addition, any server or database code updates have to be re-uploaded to the servers manually.
Besides all the efforts required to develop and deploy the app, developers need to remember that unlike Parse.com Parse-server lacks an internal Dashboard. Even though Parse released an open-source version of the Dashboard, it still demands much more work from the DevTeam than they had to do previously.
Although Parse-server doesn’t have a dedicated dashboard it has most of Parse’s features: only Cloud Jobs and Webhooks, although they have to be implemented manually, The open-source version also offers features that Parse.com lacks, for example, livequery — a query that is updated in real time. You can also add NodeJS modules to the server. The possibilities are virtually limitless.
Unfortunately, the syntax differs in some areas between Parse and Parse-server, especially in Code Cloud. For example, the Cloud object had the Parse.Cloud.useMasterKey() method removed and it was replaced by the use of a useMasterKey option. For the user identification you can no longer use Parse.User.current() but you should now use the attribute request.user to get user information. Furthermore, for queries and writes dependent on the user it’s necessary to pass the user’s sessionToken [available as user.getSessionToken(),] as an option.
Deleting objects in Parse Cloud code.
Deleting objects in Parse-server Cloud Code.
Control & Connection
Along with this package of new features and possibilities, the Parse-server gives the programmer greater control over the application since all the server code can be modified. Despite open source’s flexibility it’s important to note that this increases maintenance work: previously Parse team did all the server maintenance work and now this needs to be done by the development team.
It’s also vital to compare how changing from Parse to Parse-server alters the form of the connection in the app. In self-hosted Parse-servers there is no need to create a client-key or a REST-key and this makes it easier to connect to the server.
Another factor to consider is the price difference between the two solutions. In the case of the parse server you need to pay two servers, but in Parse you only had to pay for one. This comparison requires examining plans with similar performance on both platforms.
We will take as a hosting platform the Parsi-server Heroku + mlab set. For the comparison we will use Apache Bench software to do a performance test (15000 requests with 4000 concurrency) and compare the performance of the group’s plans to find similar plans in Parse.com.
For the test I used the Heroku’s Hobby plan, which can handle about 270 req/s — this is the equivalent of a $2400 US dollars plan in Parse. For storage Parse has 20GB available space. In mlab a 40GB plan costs $180, totalling $187. An explanation of this absurd difference in values is required:
- At the Parse-server all servers’ maintenance has to be done by the development team; at Parse this work is done by the Parse developers.
- In a self-hosting solution any new feature must come from the development team, but in the Parse new features are added by the server itself.
- Automatic scalability: at the Parse your app is scaled automatically when needed but in self-hosting solutions this must be done manually.
Now comes the question “Why compare the Parse-server with Parse as it will be shutdown in a few months?” The aim is not to compare particular solutions but models. Currently companies use solutions based on Parse (such as Back4App) to continue the model that Parse created. These solutions provide an easy migration for their servers, develop new features for the Parse-server and offer their services for more competitive prices than Parse.
Despite being a platform with a scheduled shutdown date the Parse model remains a viable alternative to backend applications since it enables developers to devote more of their time to further develop their apps instead of having to keep an eye on their databases.