Backendless 4.0 is a major release of the platform focusing on performance and productivity improvements. Parts of the system were completely rewritten to enable more flexible management of the apps and to streamline performance of the product's core functionality.
Backendless Console has been fully re-implemented using ReactJS and parts of console have rather different user interface (for example, Business Logic and Code Generation), but we hope it will be easy to get used to, especially since it provides a lot of new functionality. The primary goal of the console rewrite is to support pluggable UI modules which can be installed through the Backendless Marketplace.
Backendless 4.0 is not backward compatible with the current version. This means that an app built with the currently available APIs would need to be migrated to run with Backendless 4.0. The number of changes in your app can range from minimal to moderate, depending on the APIs it uses. See the "Differences between 3.x and 4.0" section below.
At the present moment, Backendless 4.0 is available as a "preview" (or Beta1) release in the form of Backendless Pro. While we are preparing Backendless Cloud for the launch of 4.0, we highly recommend downloading Backendless Pro 4.0 Beta 1 so you can explore the new functionality and make sure your apps work with the updated APIs. We have added a special data migration functionality to allow copying your app's data from the Cloud version to your Backendless Pro 4.0 installation. See the "Migrating to 4.0" section for additional details. The releases of Backendless Pro 4.0 will not require a license key while the product is in Beta.
The Cloud version of Backendless 4.0 is expected to be released in early 2017.
Backendless Console has been rewritten from scratch, it is a brand new product with a lot of minor and some major changes. We kept the same overall structure and improved on many parts. The console rewrite was driven by our goal to improve developer experience and build a system that would allow future expansion of the platform.
Multiple iOS certificates and Google keys can be associated with a backend and mapped to various messaging channels. When a push notification is sent to devices registered with a channel, Backendless uses the certificate mapped to the channel.
We have changed how code generation works in Backendless. Developers can now create their own code generators which show up in Backendless Console and can be used right away. In a future version, we plan to enable sharing of code generators between developers through Backendless Marketplace.
Bring the power of Serverless into your Backendless apps. The AWS Lambda integration makes it super simple to create Backendless native client libraries enabling seamless integration between your mobile app and logic in Lambda.
We made a decision to remove app versions. The amount of complexity the code supported versioning was rather staggering. If your app uses Backendless versioning, there is nothing to worry about. Multiple versions can be easily replaced by multiple replicas of the backend app. The migration process creates a new app for every version. Plus you can create unlimited number of apps, whereas versions in 3.x cost extra. As a result of this change, the “initApp” call in the Backendless SDKs does not include version name any more. Likewise, the URL in the REST API does not include the version name either.
A Backendless app is identified with two IDs: Application ID and a API key (previously called a “secret key”). These two IDs previously had to be included into an API call as HTTP headers. Starting with the 4.0 release, application ID and API key are part of the endpoint URL. This change will make it easier for us to support intelligent routing of the API requests and enable better load distribution and, as a result, improve stability and scalability of the system.
We’re introducing an important change for how relationships between objects are created, edited and removed. Previously, to establish a relationship between two objects, an app would have to call either “save” or “create” API with the “parent” object which included it’s child(ren). To break a relation, the “parent” object should must be sent to the server without the child in the collection. A lot of developers found this mechanism confusing. To streamline the process of creating relations, assigning children objects to their parent and breaking relations we now provide APIs for each of these operations.
Previously, all our APIs for fetching objects from the backend also returned the total number of objects corresponding to the search query. This applies to the “find” call in the Data Service, the “listing” call in the File Service and the “getPoints” API in the Geolocation service). The total number of found objects/files/geopoints was available in the “totalObjects” property. As applications grow in size and start accumulating a lot of data, the processing time to calculate the total object count can impact the response time. Most importantly, we noticed that the “totalObject” property was used only in some specialized use-cases. With the goal to optimize performance, we made a decision to provide a special API/REST route to retrieve total object/file/geopoint count for any given search query.
APIs returning collections of objects such as the “find” call in the Data Service or “listing” in the File Service used to return an instance of the BackendlessCollection class. The class was used to hold on to the collection of data returned from the backend and the “totalObjects” property described above. Now that “totalObjects” is retrieved through a separate API, BackendlessCollection is not needed anymore. As a result, all the APIs which used to return BackendlessCollection now return native collections for the corresponding programming environments (java.util.Collection for Java, array of objects in JS, NSArray for iOS).