Parse StackMob and Kinvey at WAR
In the first part of this series we covered basic features of backend as a service provider. In this part, we will have a look at three major services (Parse, StackMob and Kinvey) and compare them. Each of these services have their own unique strengths. Based on your preference, you can choose one of them. The three BaaS providers we will compare are Kinvey, Parse and StackMob alphabetically.
Currently, Parse is one of the most well known service providers among all Baas providers. The feature set is fairly vanilla and is aimed squarely at the mobile space (there are plenty of unofficial wrappers around the ReST API for all but the most obscure languages) and lacks some of the bells and whistles that for ex. StackMob has but keeps the feature set lean and neat.
Parse provides single instance data store which is unversioned and schema-less (no switching between test and production – though you could theoretically use separate apps for that) . The schema is constantly adaptive that means when you send objects with a new property, it just adds another column to the collection to support that property. This is useful especially when data is sent in the tightly controlled environment of a mobile app and strongly typed classes. Parse supports storing binary formats as well (stored on Amazons S3) and integration with uploading and storing is built right into the SDKs.
One of unique things about Parse iOS SDK is Parse powered UI components. The common ViewControllers are for signup/login, for collection backed tables (with querying built in) and for displaying images are available OOTB.
iOS SDK is rich in Parse powered UI components which makes Parse unique. The common ViewControllers are for signup/login, for collection backed tables (with querying built in) and for displaying images stored in Parse. This controllers makes Parse, a tempting service for a weekend hack.
Pricing for Parse is costed on a per account basis rather on typical per-app basis and one million API calls per month for free. However, Parse becomes expensive when your app/apps starts creating API calls in bulk. The gap between the two main pricing tiers in Parse is very large. You either pay nothing or you pay around $200 per month but wait, before you choke on whatever you may be eating, when limit is reached, you don’t have to pay $200 per month fee, its just around 7 cents per 1000 API calls you need to pay. So unless app is constantly hitting around the 4 million mark every month you should be fine. Just be ready to pay if your app makes it big :)
StackMob offers native SDKs for iOS and Android and in addition offers lot more features other than basic BaaS features. Lets have a look on both typical BaaS features of StackMob and addition features it provides.
When you create a new app on StackMob you get two environments, one for development and one for production. In development mode the data store behaves like in Parse – sending new properties into a created collection type will result in new columns in the schema. However when you move to the production environment it becomes impossible to over-post.
The StackMob schema supports relationships as well. You can use the online schema designer to define these relationships and pass in flags to API requests to pull back these relationships in the forms of nested collections. For customers willing to pay, StackMob supports versioning of your apps API.
Finally StackMob supports binary storage but unlike Parse this isn’t rolled directly into the SDKs. Instead you can link an Amazon S3 account with StackMob and then you can upload to S3 from the SDKs.
iOS SDK Core Data
StackMob recently announced a complete rewrite of their iOS SDK. This rewrite has introduced Core Data integration which provides powerful mechanism for synchronisation between the device and StackMob. It also offers a very familiar interface for iOS developers used to perform powerful data binding between UI elements and data store.
In addition to typical BaaS features, StackMob is a PaaS for HTML5 apps. The StackMob powered apps can be hosted directly on StackMob itself. It also supports post commit hooks with GitHub which enables connecting StackMob app with a Github repository and deployment becomes as simple as pushing to a branch on GitHub.
Ability to execute custom code on server is one of the most unique features provided by StackMob. Server code can be written in Java, Clojure or Scala. Once code is compiled and packaged into JAR, you can expose it as another ReST endpoint in your application. The contents of the JAR has access to a sandboxed environment within StackMob. You can read and write to apps data store, make use of a logger for debug purposes and have access to an HTTP Service which gives has the ability to integrate with third party services.
To me this is an essential feature for any service wanting to go beyond purely mobile apps. With no access to the server in a typical BaaS system you’ll be required to implement certain business logic in your client that really doesn’t belong there. While this is fine for mobile apps where users can simply right-click and view source, it becomes a liability for web apps where this logic can be easily circumvented. Without checks on the server-side your data can be easily polluted. For example, if I wanted to write an app that only accepted email addresses from a certain domain, I could write a bit of server code to validate this making it much harder to circumvent. Further, I could also use the HTTP service available to custom code to integrate with an email service such as MailGun to send a confirmation mail – something that would otherwise require embedding all your application tokens and API keys into the client.
While you could achieve all of this by simply hosting your own service elsewhere, the all-in-one approach of StackMob certainly helps reduce friction and speed productivity.
StackMob’s pricing is a little more granular and it seems to be a more expensive option on the surface, this isn’t necessarily true. What is true is that you will start paying sooner but the price you pay rises more gradually when compared to Parse. StackMobs pricing is calculated on a per app basis (rather than per-account) and this makes pricing even more granular if you are supporting more than one app. Again, between the different pricing tiers you have the pay-as-you-go option.
Full disclosure – while I have known about Kinvey for as long as Parse and StackMob I have much less real experience with it. On the surface it seems like a fairly vanilla offering but there are some very interesting reasons to look into Kinvey.
In ReSTful APIs, versioning is an essential feature. When you want to release new features, versioning can help with backward compatibility and prevent breaking changes from breaking things. Parse doesn’t support versioning and StackMob offers it at a significant premium. With Kinvey it is just another feature and if you can predict a need for it Kinvey is certainly worth investigating.
JS SDK Offline and Caching
When compared via number of API calls over the ReST API, Kinvey is consistently the least expensive option out of the three services – sometimes by a large margin – especially when the number of API calls start hitting the 10 million mark.
However Kinvey actually have 2 pricing methods. One for native apps and other for ReSTful API calls. Native applications are costed against the number of active users per month (an active user is defined as any user that makes at least one API call in the month). The API call approach is calculated in the same manner as Parse and StackMob but looking at the API call costings, Kinvey seems to offer the best of both Parse and Kinvey. Firstly,you get a very generous one million API calls per month for nothing, and secondly this is costed on a per-app basis.
Do you want to quickly build an iOS app without worrying about wiring up the data store? Parse would fit well there. Need to execute custom business logic? Try StackMob. Working to a tight budget or have a varied growth model? Kinvey might just save you a heap of money. This is only a small number of the factors worth considering – each platform will offer more features than anyone could possibly talk about in a single article. Simply put – there is no one-size-fits all Backend as a Service provider out there. As with almost every technology decision choosing a BaaS service will come down to project requirements.