Backendless Release 1.9.0 – Geoclustering, Data-to-Geo object relations, improved GIT integration and "export-as"

by on February 12, 2015

I am very happy to report that we released a new version of Backendless. The new release is tagged as version 1.9.0, which is a new numbering scheme for us – we used to label releases with names attached to various events.

The new release is packed with features, improvements and bug fixes. I’d like to review the most significant ones and will be writing more in detail about each in my feature-a-day blog series.


Suppose your geolocation Backendless storage has a lot of geopoints. Plotting them all on a map would yield a substandard user experience. A common practice is to visualize these points as “clusters”, where a cluster may represent a group of two or more geopoints. Users may zoom in on the map or “expand” a geocluster to dig into it and get the points it consists of. With this new release, we’re delivering the functionality of Geoclustering. Both our APIs and Backendless console have been updated to support the feature. Applications can retrieve geopoints using the API and request a “clustered” view. As a result, Backendless will return the results as a collection of Geocluster objects. Geoclustered searches work for searches in a rectangular areas on the map, radius or across geocategories.


Backendless supports persistence of complex object hierarchies. Until now, you could create these hierarchies by relating objects from different data tables through object properties. Starting with 1.9.0 we’re expanding the nature of the relations a data object may have by introducing data-to-geo relations. A data object may have a related geopoint (one-to-one relation) or a collection of geopoints (one-to-many relations). The beauty of the integration is these data-to-geo relations work exactly the same way as the basic data-to-data relations.

To express these relations in the code, your entity class can declare a property/field/getter of the GeoPoint type (or a collection of GeoPoints) and Backendless takes care of the rest. All the persistence, data synchronization, lazy initialization, auto-loading tasks are transparent. Additionally, we updated Backendless console to visualize the data-to-geo relations. It is super-easy to navigate from a data object to a related geopoint. You can declare data-to-geo columns in your tables, manually link data objects to geopoints, update or delete these relationships. There is a lot more to it and I will be spending some time digging into this fantastic feature.

Also, I’d like to mention that the integration is bi-directional. It means that not only you can create relations from data objects to geopoints, but the other way around as well. A geopoint may have a related data object through its metadata.


One of the hidden gems in Backendless Console is a feature called REST Console. It is available on the Data screen in a little self-titled tab. The REST Console gives you an ability to execute and inspect REST requests and responses for a complete CRUD (Create, Retrieve, Update, Delete) set of operations on your data tables. Using the REST Console GUI, you can select any number of options for the request (sorting, loading relations, selecting properties to load, paging, etc) and execute the requests. The new feature we added in 1.9.0 is called “export-as”. Once you run a REST request, you can “export” it in the format of other languages. That means the feature will generate code in the language of your choice which will run exactly the same request you saw running in the REST Console. Currently the number of languages/frameworks we added is rather small. It includes cURL, Backbone.JS, XHR and jQuery AJAX. However, we will be expanding this section with every imaginable language and framework.

Improved Git Integration

Git integration is not a new feature in Backendless, however, in 1.9.0 we have completely reworked it. Starting with 1.9.0, the integration is completely bidirectional between the file storage allocated to your app and the Git repository. It means any files you upload through the API or Backendless console will be added, committed and pushed into the Git repository. Similarly, any changes you make directly in Git will be reflected in the file storage. In other words, the file storage which you can navigate in Backendless console is a mirror (physical) copy of your Git repository maintained by Backendless.

We hope you will enjoy using these features as much as we did developing, testing and documenting them. If you run into any problem, please do let us know!

Leave a Reply