Backendless Cloud V3.0 for iOS Review
Backendless is one the newest additions to the MBaaS (Mobile Backend as a Service) playing field, with development having started in 2012. It has quickly evolved into a solid alternative at a time when players are trying to grab as many Parse users as they can after parent company Facebook announced in early 2016 that it is shuttering the Parse platform on which 600 000 apps were built.
Backendless provides three product versions:
For this review, we tested Backendless Cloud’s free SDK for iOS.
Backendless Cloud offers all the essential and common features we have come to expect from an MBaaS provider, and also delivers value-add features such as media streaming. This review will focus primarily on the functionality and quality of the essential and common features.
Authentication and User Management
Backendless Cloud offers an intuitive interface for easy monitoring of user account information (e.g., when users have logged into the system) and managing account details such as user properties, passwords, and enabling or disabling users. The console also allows developers to manage authentication-related notification triggers such as sign-in and first login as well as the look and feel of these notifications using email templates.
Login using social accounts is now a generally expected feature of robust authentication support, and for this Backendless has integrated with the usual suspects: Facebook, Twitter and Google +.
With Backendless Cloud, creating, retrieving, updating and deleting data is quite simple thanks especially to easy-to-use filtering and built-in paging support, though SQL queries are used so familiarity with SQL is beneficial. There is also no need to create mappings or deal with JSON of any kind through the iOS library as all the common data types are automatically mapped within the objects. With this, Backendless Cloud is a step ahead of competitors such as Kinvey and Firebase.
Sending files is similarly easy. The upload API expects NSData objects and will spit out a URL with the downloadable file. The uploaded files, including their respective security permissions, can be managed through the console.
Backendless seems to be reluctant to take part in the SQL vs NoSQL war as they say they use both. Nevertheless, Backendless expects its users to model data in a relational manner as if it were 100% SQL. For this, developers can make use of the schema editor tool within the console, which makes the data modeling quite easy.
Backendless Cloud does not support offline caching, something which most competitors, including Kinvey and Firebase, do offer. This is a feature that has been requested on the Backendless online forums, and though the company has acknowledged this and has promised to add it in the past, we haven’t seen anything yet as of the tested release. As most apps will need offline support, a developer utilizing the Backendless SDK would be faced with the added hassle of providing this functionality.
Badge, sound and alert notifications are supported and can be sent through the console or published via API. The push notifications can be sent to all devices or to certain devices based on operating system or custom selection. Backendless provides segmentation that is sufficiently granular for allowing the user to group users in various ways, such as by pre-selected user roles (for example, users signed in by a specific social media channel) or to manually selected devices. Though message publishing is generally easy, manually entering headers can be cumbersome.
In reviewing the security features, the company states that Backendless Cloud offers a finely-grained user policy, provides protection for data, users and files, secures and encrypts all API traffic, and stores sensitive data like passwords in a manner that makes it impossible to retrieve the original values. So how does it stand up to these assertions?
Developers can set up different control lists as well as group users in a variety of ways, granting the groups actions such as adding geo-points, updating data or subscribing to message posts, thereby making parts of your app accessible only to some users by using the console. The fact that you can do this attests to Backendless’s claim that they have a finely grained user role policy.
However, despite what Backendless says about data, users and files being securely stored, all API traffic being encrypted, and passwords being stored using one-way hash/salt encryption, we do have a couple concerns about security best practices:
Backendless Cloud has a built-in analytics package that offers general insights based on captured runtime information. Users can analyze API usage at the service and method level, view the dynamics of user growth, and analyze messaging activity. So, in effect, you get basic analytics functionality. While this will get you started with tracking general user metrics such as app traffic, third-party solutions like Google Analytics or Flurry would be required for more advanced metrics.
Backendless Cloud makes it relatively simple to deploy custom business logic on the server side, which gives users the power to centralize application logic and extend/override the default service behavior. Events like creating or updating data as well as timers, both of which can be used as triggers to run the code, can be created through the console.
Backendless Cloud will also generate Java code for custom implementations. The code can be downloaded and debugged locally before being deployed to production. This ability to deploy custom server-side code is generally a really nice bonus feature that any MBaaS should offer.
Backendless also includes the following additional features, which are not generally thought to be integral to an MBaaS.
It’s not uncommon for an MBaaS to include geolocation in its service offering, and Backendless Cloud is no exception. Backendless’s service provides APIs for storing, searching and managing geolocation data. Geopoints can be added and updated as needed and searches can be run in rectangular or circular areas on a map to, for example, send out messages to users within these geographical boundaries.
In testing, we ran into issues with this feature where, in certain instances, messages were not triggered when a user entered, stayed in, or exited a geofenced area.
Publish/Subscribe (pub/sub) messaging is used for broadcasting important information and data updates. It is generally not thought of as a core feature of an MBaaS though we think maybe it should be as it injects enough added value that it should be included in any MBaaS.
Backendless Cloud provides the APIs and the functionality for receiving messages on any platform, processing them, and subsequently delivering the messages to subscribers. Users have a choice between a polling approach, where the app sends periodic requests to retrieve published messages, or using push notifications to achieve the same result.
The system supports message filtering and conditional message delivery. Additionally, developers can override default message routing with custom business logic.
With media streaming, Backendless Cloud allows an app to broadcast media. Backendless states that its iOS SDKs include APIs to add on-demand media publishing and live streaming with a mere few lines of code, and that the audio and video content can be broadcast across platforms. For example, if media is broadcast on the app on an iOS device, it can be viewed on an Android version of the app without issue.
The media can be controlled from the console, where developers can view streams, configure parameters, and assign user/role-based permissions.
The library for iOS is written in Objective-C and it integrates as well as expected with a Swift project. Installation is also very simple and can be done through Cocoapods. Two pods are available as media support is an optional feature.
The API is well documented and easy to use but it feels like it’s going through an identity crisis. There are multiple ways to accomplish a single task, be it Synchronously or asynchronously, with a custom responder or the usual callback block. And for whatever reason, Backendless decided they didn’t like NSError well enough. You’ll get a Fault object with the custom responder or anywhere you expect an error, for that matter.
Performance – Data Downloads
Performance was tested by trying to ascertain the maximum number of concurrent connections that the API can sustain and how quickly the database can process and respond with information to complete the request. The metric is defined as the number of requests per second that bring our API server to maximum CPU utilization without returning errors or timing out.
During testing, Backendless Cloud was observed to handle up to 700 requests before the server reached 100% capacity and requests began failing.
The retrieval of various amounts of data (50-100 data items) was tested using various numbers of users (1-200) to gauge response times. This testing was done over Ethernet and LTE network connections. Ethernet was used to provide a more stable network environment and LTE to provide a mobile environment. Backendless Cloud limited access to a maximum of 100 data items per request. This was a clear limitation as more calls would have to be made to access the remaining data while, according to our performance tests, competitors such as Kinvey allowed access to more than 100 data items in each request.
During testing, the average response time for 1 to 50 users retrieving different data sets was observed to be around 1 second. When the number of users or the data set size was increased, we observed a slight increase in response times. The response time for a single user was observed to be more than the time it took 50 users to access the same data set.
The throughput for a single user was observed to be relatively low but rose significantly as the number of concurrent users increased. It was also noticed that, for the larger data set (100 items), the throughput was lower than that of the smaller data set (50 items) when the number of concurrent users was more than 50. For example, with 50 users, the throughput for 50 and 100 item was 2009 KB/s and 2274 KB/s respectively. But when the number of users was increased to 150, the throughput for the same data sets was 4985 KB/s and 4205 KB/s respectively.
The following graph displays the scenarios that were tested during data performance testing:
Performance – Image Downloads
When multiple users connect to a single server, they share the same bandwidth to download content. Therefore, in order to know how many concurrent connections the server can support without having any connection issues, it is important to know the highest data transfer rate (kilobytes per second) that a server can support.
To attain the highest data transfer rate, we attempted to download a 450 MB file from the server with as many users as possible. The highest recorded data rate was 80 MB/s when downloading the 450 MB file.
When downloading images, we measured the throughput and average response times for each connection. Throughput helps us to understand the rate at which data is transferred and the average response time helps us understand how many milliseconds it took to complete the request for a user. By using throughput and average response time, we can understand how fast and how much load the MBaaS handle with different numbers of users before slowing everything down. For this test, we used 127KB, 478KB, 1MB and 5MB images with a varying number of users. These tests were also executed over LTE and Ethernet network connections.
For smaller images (127 KB and 478 KB), we noticed that there wasn’t a major change in the response time when we increased the number of users. The average response time always remained below 500 milliseconds. With images, the download times for 1 user were generally longer than for 50 users, though the 1MB and 5MB images took much longer when we increased the number of users.
The throughput was observed to increase as the image size and/or the number of concurrent users increased. For example, the 1MB image had twice the throughput of the 478 KB image when 50 users were concurrently downloading the image. When we increased the number of users, the throughput also rose significantly. For example, 100 users downloading the 127 KB image had a throughput that was twice that of 50 users.
The following graph displays the scenarios that were tested during image performance testing:
Testability, defined by applying the concepts of observability and controllability, allows QA to identify the areas to test and, for each feature, what tests can be performed, and how to perform those tests. If the testability of the SDK is high, then the probability of finding faults in the system by means of testing is greater. This also helps us gauge which tests provide us with the most confidence and correctness.
Backendless makes it easier to test some of the features with its built-in console, which allows direct viewing, editing and debugging of the database. This is particularly useful when testing and debugging the backend. Also, it lets users search for data by typing in strings or executing queries, which means even people with no technical knowledge can access specific data easily. However, the search feature is not perfect. For example, a partial search won’t find a record unless the user enters the first character of the searched for record. The search feature is slow, and its user friendliness would benefit from minor improvements such as by implementing persistent sorting and filtering. In addition to being slow, it is really easy to make mistakes and corrupt the tables and data. For example, if a user tries to add data to a column that doesn’t exist, it automatically adds the new column to the table without asking for confirmation.
Entering a query can be frustrating as the system tries to perform the search after each character is entered even though the query might not be complete. As a workaround, a query can be pasted into the field to avoid this auto-search, but even then you need to enter the last character in the field to execute the search because just pressing enter won’t execute the search.
Backendless Cloud’s features can be tested using the Backendless API, demo app requests, and a third-party API such as Postman.
Features can be tested as follows:
Authentication and User Management
Messages can be sent as push notifications to devices. The Backendless console or a third-party API can be used to publish push notifications.
Media and File System
Backendless can be deployed on all major cloud environments, including AWS, Google Cloud, VMWare vCloud Air and Digital Ocean. Local installers are also provided for Mac OS, Linux and Windows operating systems.
The Backendless console includes an option to export the existing application settings, data service and geoservice, or do an import. However, these features are not bulletproof. For example, when an import fails, it can be very difficult to track down the issues for the failure.
With the free version of Backendless Cloud, you cannot add a new version of your environment for testing and deployment. For this, you would have to have a paid version of the SDK.
Video demonstrating deployment of a service. Source: Backendless.com
Backendless provides robust product support that includes a knowledge base, video tutorials, webinars, and a support forum, not to mention a Parse-to-Backendless migration guide. Participation by multiple developers on the support forum should be lauded, and CEO Mark Piller is very hands-on with customer support, responding to developer questions, writing guides, starring in video tutorials and presenting webinars.
Documentation for the iOS library is sufficient. It covers all features, with examples in both Objective-C and Swift, and screenshots that help depict how to set up items in the console. Some of the iOS documentation is outdated, as is the case with push notifications, though most of the setup for pushes is generic enough so it is not a major concern.
The downside is that support requests can get costly at least at the lower price tier, though competitors such as Firebase have also instilled limits to direct support requests.
Backendless updated their pricing model for Backendless Cloud on February 1, 2017. This comes a day after Facebook shuttered Parse once and for all. The pricing remains fairly uncomplicated compared to some competitors in this category. The free option is decent, offering a minimally required set of features that should be sufficient for getting started with an app. The general limits increase and restrictions decrease with the paid plans, which come in two tiers at $25 and $99 per month.
Backendless sends email notifications to users of the free tier when their usage begins to approach or exceeds limits, allowing for an upgrade to a paid plan. The limits can, however, come up fast so it’s important to stay on top of, for example, user traffic to avoid calls being blocked.
Some specific limits, such as file storage, can be increased individually by purchasing what the company refers to as Function Packs that cost anywhere from $5 to $100 per month depending on the item.
In terms of cost benefit, Backendless Cloud’s free tier delivers a good product despite some of the drawbacks and limitations we covered earlier. It offers most of the core features expected of an MBaaS, and implementing the features didn’t require excess sweat equity, which is where some free products can fail and make them a costly acquisition.
The Final Word
Backendless Cloud’s free tier is a generous offering that will get app developers started until the app gets real traction, at which time one of the higher tier options will be a more suitable option.
Features were generally easy to use and well designed, and the libraries are easy to set up and suitably integrated with iOS. Most features worked as expected or above expectations, with only some minor negatives to point out.
On the upside, creating and managing users is easy and well documented. When it comes to storage, Backendless Cloud also covers the bases as it’s a snap to create, retrieve, update and delete data. Data modeling is also equally intuitive with the use of the schema editor tool in the console. When it comes to business logic, Backendless has really hit the mark. Not only is deployment of custom business logic relatively simple on the server-side, but the ability to deploy custom server-side code is a really nice bonus feature.
We did have some concerns with security, offline caching and some annoyances with the console. As we mentioned earlier, the use of http over https as well as the use MD5 to store passwords do not make for best of class security. Though the feature set is robust, the lack of offline caching stood out. The web console’s user-friendliness also could also use some improvements as its current functionality was less than stellar especially with regards to the quirks of the search function.
Backendless is a young company that has stepped into the MBaaS space at the right time, and they are doing a lot of things right with this product. With continued improvements, it will be interesting to see what lies ahead as the pieces fall in the wake of Parse’s departure as developers are undoubtedly looking for a successor platform that will display long-term support for a their time and resources investment.
The following is our rating scorecard for Backendless: