This article is targeted at Telerik Backend Services customers who are exploring the steps to migrate their existing Telerik Backend Services apps to Kinvey.
It presents an exhaustive comparison between the features available in Telerik Backend Services and their Kinvey counterparts. You can read about the notable differences as well as suggested migration paths. The Data Field Mapping Reference document contains additional reference information that can help you plan your development or migration efforts.
This article also outlines Kinvey features that are not available in Telerik Backend Services.
Content at a glance:
- Migration Glossary
- Cloud Data
- Cloud Files
- User Management
- Data Connectors
- Business Logic
- Push Notifications
- Other Features
- Deployment and Compliance
Backend Services and Kinvey often use different terms for similar features. In the table below, you will find a list of fundamental terms used in Backend Services and their counterparts in Kinvey.
|Telerik Backend Services Term||Kinvey Term|
|App Id or API key||App key + app secret|
|Master key||Master secret|
|Type, content type||Collection|
|Data item, item||Entity|
|Type-level permissions||Collection Permissions|
|Item-level permissions||Entity Permissions|
|Data Connectors (feature)||RapidData|
|Data connectors (all defined connectors)||Services, Service catalog|
|Type from a Data Connector||Service object + collection|
|Cloud code for data||Collection hooks|
|Cloud function||Custom endpoint|
|Scheduled job||Scheduled code|
Similar to Cloud Data in Telerik Platform, Kinvey offers a No-SQL cloud data store. It is a non-relational store powered by MongoDB.
In Kinvey you can execute CRUD operations on data similarly to the way you do this in Telerik Backend Services, with several notable differences:
- No batch create—it is not possible to create multiple items with a single request in Kinvey. As a workaround, execute several CREATE requests in parallel.
- No partial update—in Kinvey, you cannot update only part of an item. Instead, you always need to update the whole item, e.g., send all fields. As a workaround, fetch the item before updating it, make the changes you need and then send the UPDATE request.
- No update by filter—in Kinvey it is not possible to update items by filter; you can only update by Id. As a workaround, you can implement a batch update operation using business logic.
- Expanding relations—you cannot fetch items and automatically expand their relations in a single request. This is possible out of the box for referenced files as explained here.
Upsert—in Kinvey, you can issue a PUT request by specifying the item
_idand the item will be either created or updated if it already exists.
- Result Set Limit—if the response of your call to the server returns more than 10 000 items or exceeds 100 MB this will result in an exception from the server. Consider using the pagination options if you expect to exceed these limits.
No Inline Count—the response to the request does not include the count of the number of entities in the collection of entities. Usually this is used for calculating the all pages’ size for pagination scenarios. To calculate the count of entities in a collection you may use a separate request or use the
onPostFetchhook in the Business Logic layer to include the count of items in the response.
Querying your cloud data in Kinvey is very similar to querying cloud data in Telerik Platform Backend Services. Keep the following limitations in mind when planning your data querying patterns and operations:
No querying headers—to construct the query you need to use query string parameters (
limit, etc.) as opposed to Backend Services where you can use both URL parameters and custom headers. This affects only users of the RESTful API; the querying procedure in Kinvey's client SDKs is transparent to the developer.
- No fields exclusion—to return a subset of fields in Kinvey, you need to list all their names with the query. Excluding one or more fields is not supported.
No "contains" filtering—when searching for a value in a string field with the
$regexoperator you are limited to searching the beginning ("startswith") or the end ("endswith") of the string.
No case-insensitive string search—when searching for a value in a string field with the
$regexoperator the search operation on the server can be only case-sensiitive.
You can read more about the querying restrictions and limitations here.
Data aggregation is supported in Kinvey, but its usage is a bit different than in Telerik Backend Services.
In Kinvey, aggregation is based on the map/reduce concept. You can read more about it here.
Unique fields are not available in Kinvey. As a work-around you can ensure uniqueness using business logic.
In both Kinvey and Telerik Backend Services there are some system fields that are automatically maintained for each data item.
Below you can find a table with the system fields created in Telerik Backend Services and their equivalent in Kinvey:
||The ID of the item|
||ID of the user who created the item.|
||Date and time when the item was created.|
||N/A||ID of the last user who modified the item.|
||Date and time when the item was last modified.|
||Owner of the item.|
Note that in Kinvey there is a single field for the owner and the creator of the item, meaning they are always the same.
To set custom values for the system fields you must use master secret authentication.
Kinvey uses a similar security model to Telerik Platform. You can control access to data on a collection or entity level as detailed here.
The policy-based and role-based type-level permissions that are available in Telerik Platform are available in Kinvey through Role-based collection access, with some notable differences:
Role-based access only (no predefined security policies)—In Kinvey, you can mimic the predefined security policies known from Telerik Platform through setting the respective access types over a collection for a given role. For instance, to mimic the "Private" security policy available in Telerik Platform, you need to create a role and set its permissions over a Kinvey collection to the following access types: Create:Always, Read:Entity, Update:Entity, Delete:Entity. This means that anyone can create an item, but only the creator (as set in the entity) can read or modify the entity by default (if no entity-level permissions are set).
Mixed precedence—in Telerik Platform, role-based permissions are always overridden by item-level permissions. In Kinvey, there are different precedence levels. For instance, if the access type of a role is set to "Never", this takes precedence over any other access type and granted permissions (even on item level).
In Kinvey you can define a more granular control over the access to a data item, similarly to item-level permissions in Telerik Platform. In Kinvey they are kept in the
_acl field for each entity.
The notable differences include the following:
- In addition to setting a user and/or role that can read/write a data item, you can specify access level for a user group.
In Kinvey you control access for "everyone" on an entity permission by setting the Global Access Control.
You can save and query data based on geolocation information in both backends. In Telerik Backend Services, you needed to create a field of type Location. In Kinvey, you need to use a specific field for geolocation data named
_geoloc. It is an array-type field that stores the longitude and latitude values:
You can store your files in the cloud with Kinvey, the same way you do with Telerik Backend Services, with the following differences:
File upload—a file upload is completed in two steps: inserting the file metadata followed by uploading the file content. If you use one of the SDKs, you will not feel any difference working with files between Backend Services and Kinvey.
File upload in base64 format—uploading files in base64 format is not supported. Consider using another method such as multipart/form-data.
Permissions—in Kinvey you can control whether the actual file content on the Content Delivery Network is public or not.
The Kinvey user management functionality is similar to what Telerik Backend Services offers. You will find the notable differences in the sections below.
CRUD operations on users are very similar to those in Telerik Backend Services. Notable differences:
- Anonymous registration—you can register a user in Kinvey without specifying username and password; Kinvey autogenerates them for you and returns them.
- Disabling users—In Kinvey, it is possible to suspend a user so that the user cannot log in. In Telerik Backend Services, you have to delete the user in order to prevent log in. You can read more about suspending users in Kinvey here.
- User discovery—In both Telerik Backend Services and Kinvey, the permissions of the Users content type follow the same concept as the other data types’ security. In Kinvey, however, you have the additional option to protect the privacy of your users, but still be able to discover users from the mobile app. Use the "lookup" method (and set security to Private). You can read more about that here.
Email address is not unique—Kinvey does not enforce uniqueness on the email address value stored in the email field when registering user accounts. Multiple user accounts can be registered with the same email address. Similarly to Backend Services, however, a unique constraint is enforced on the
You can assign user accounts to roles in Kinvey in a similar fashion as in Telerik Platform.
Role-based access control in Kinvey introduces a few differences:
- A user account can have more than one role.
- As opposed to Backend Services, you cannot set a default role for the application that automatically accommodates new users. Kinvey does offer the system-created "All Users" role which always contains all application users, but you cannot unassign it from users. You can create as many roles as you like and give them different permissions over a collection, but you need to manage membership yourself.
- The "Owner" role in Telerik Platform (which by default is the creator of a data item) does not have a direct counterpart in Kinvey. By default, the creator of the item acts as an owner of that item and can be granted access by setting the "Entity" access type.
- Deriving from the above, you cannot explicitly set the "Owner" of a data item. In Telerik Platform, this is usually used when you are granting access only to the Owner of an item with type-level permissions. If you need to do the same for a collection in Kinvey, you need to use the other available methods for determining the access control for a data item. For instance, you can either modify the creator (in the
_acl.creatorfield of an item) or set another user, group, or role to be able to read and/or write the item and remove the item creator from the item’s
_acl.creator. Use this approach in conjunction with setting the respective access type for a role to the collection.
More on securing access with roles is available here.
More on working with roles is explained here.
The integrated password management features are an important part of the user management facilities of both Telerik Backend Services and Kinvey.
Below you can find the notable differences in the password management functionality:
- No secret question/answer—In Kinvey, there is no secret question/answer functionality out of the box. Still, it is possible to implement this using business logic. For example, you could save the secret question and answer values at the time of creating the user account in a backend collection.
- Password change—When changing your password in Kinvey, it is not necessary to provide your current password. Depending on the permissions set to the Users collection, a user may change a user account password as any other data the user is allowed to write.
- Token invalidation—In Kinvey, when a user changes a user account password, the existing access tokens are always invalidated. You cannot specify whether you want to keep them or not.
When it comes to authenticating your app users, the following notable differences apply:
- No unauthenticated requests—In Telerik Backend Services it is possible to make requests even if you are not authenticated in any way. Such requests are processed as anonymous requests, using the permissions of the Anonymous role. In Kinvey, it is impossible to make unauthenticated requests. You must always provide some kind of authentication.
- Unverified log-in—In Telerik Backend Services, it was possible to log in to a user account, even if the user was unverified. In Kinvey, there is an option that allows you to prevent unverified users from logging in. You can read more about that here.
Both Kinvey and Telerik Backend Services have out-of-the-box integration with various social authentication providers.
The comparison table below details the support in each backend.
|Social Provider||Support in Telerik Platform||Support in Kinvey|
|Yes, out of the box||Yes, out of the box|
|Yes, out of the box||Yes, out of the box|
|Yes, out of the box||Yes, out of the box|
|Microsoft||Yes, out of the box||Yes, through MIC|
|No||Yes, out of the box|
Note that MIC (Mobile Identity Connect) is only available in the Business and Enterprise editions of Kinvey.
The following notable differences apply when using authentication with social identity in Kinvey:
- **No need to explicitly enable the social provider **—in Kinvey, outside the MIC feature, you can start signing in your users without explicitly enabling the social authentication providers.
Google sign-in does not support
id_token—when using social sign-in with Kinvey outside the MIC feature, you cannot use the Google ID token
id_token. Ensure you are passing a Google
- Automatically generated usernames and passwords—In Kinvey, user accounts created from social identities receive automatically generated usernames and passwords. Do not use these credentials for signing in the user.
Integration with enterprise authentication providers is supported in both Telerik Platform and Kinvey with some differences. Below you will find a table with what is supported.
|Enterprise Provider||Support in Telerik Platform||Support in Kinvey|
|SAML||Yes, out of the box||Yes, through MIC|
|AD FS||Yes, out of the box||Yes, through MIC|
|OAuth 2.0||No||Yes, through MIC|
|OpenID||No||Yes, through MIC|
Note that MIC (Mobile Identity Connect) is only available in the Business and Enterprise editions of Kinvey.
In Kinvey, you can create a list of user accounts, which represents a user group. User groups can include other user groups.
In your app, you can restrict access based on groups. This control is applied on entity level. For example, you could create a group called "Followers" in a social app and then use membership to determine who can read the posts of the followed user . You could set the "Entity" access type for the respective collection which would ensure that the permissions set on entity level are recognized. On the other hand, users in the "Administrator" role may be granted access to all posts.
You can read more about user groups in Kinvey here.
In addition to the supported social and enterprise authentication providers, Kinvey provides an option to implement custom authentication mechanisms that integrate with any authentication provider. This option is not available in Telerik Platform.
There are two ways to approach a custom integration:
Note that both features above are part of MIC (Mobile Identity Connect) and are only available in the Business and Enterprise editions of Kinvey.
The Data Connectors feature in Telerik Backend Services allows you to easily expose data from external data source and make it available in your mobile apps. In Kinvey, this functionality takes two flavors:
- RapidData—a multitude of connectors to popular data services and on-premises data sources that can be set up with as little effort as possible
- FlexData—a way to connect custom external data sources
In Kinvey, the definition of a connection to an external data source is called "service". This is the equivalent of "Data connector" in Telerik Platform. While Telerik Platform data connectors can’t span the boundaries of a single application, Kinvey services can be defined on either application or organization level.
After you define a service, you need to create a service object and map it to a collection in order to actually expose the data. For comparison, in Telerik Platform, the same is achieved by creating a content type from a data connector.
Below is a table with the supported data stores in both Kinvey and Telerik Platform. Note that many more data sources are available in Kinvey through DataDirect Cloud integration.
|Data Store||Supported in Telerik Platform||Supported in Kinvey|
|Microsoft SQL Server||yes||yes|
The on-premises connector software (known as a Data Link server) is not available in Kinvey. You need to connect directly to the data store from the cloud. To tighten the security, you can choose to whitelist only the Kinvey IP addresses.
An alternative for clients with a dedicated Kinvey instance is to connect over VPN to your network and only expose your data store there.
In Telerik Platform, it is possible to invoke stored procedures and functions through data connectors. This feature is not available in Kinvey.
In Kinvey, it is possible to expose data not only from well-known external data sources, but also data coming from a custom REST APIs. read more here.
Compared to Telerik Backend Services, Kinvey makes it possible to create custom data connectors. This gives you the ability to connect to any data source that you might be using, even if it is not readily available in RapidData. read more here.
Similarly to Telerik Backend Services, Kinvey supports cloud caching. This is the ability to cache external data inside Kinvey, so that it can be accessed quickly, without making a round trip to the external data store.
Cloud caching is extremely useful when the external system or the connection to it is slow. You can read more about Cloud Caching here.
Business logic in Kinvey is similar to business logic in Telerik Platform, but also supports more advanced enterprise scenarios.
There are two types of business logic in Kinvey:
- Custom endpoints are the equivalent of Cloud Functions from Telerik Platform. Custom endpoints allow you to bind the execution of custom code that lives in the cloud to an endpoint.
Collection hooks are the equivalent of Cloud Code for Data from Telerik Platform. Collection hooks allow you to intercept CRUD operations on your data and execute custom code at the right moment. One notable difference is that in Kinvey the "create" and "update" operations are both treated as a "save" operation that comes with the respective
Scheduling custom endpoints to run with custom recurrence is also supported.
While the cloud code API that Kinvey provides is different from what Telerik Platform comes with, it offers roughly the same features.
collectionAccess module to access your Kinvey data.
In Kinvey, you can use a good number of external libraries and integrations in your code. Find a list of modules you can use here.
One useful feature that is only supported in Kinvey is the ability to have common code.
Common code allows you to write frequently used functions and code pieces and then reuse them from all your custom endpoints or collection hooks.
This type of Business Logic allows you to set an interval for the execution of a given custom endpoint.
Refer to this article for an introduction to Scheduled Code.
In addition to Business Logic, Kinvey provides a more advanced way of creating server-side logic called FlexServices. Those are microservices that run in the cloud and can be used for both custom endpoints and collection hooks.
FlexServices allow for more advanced scenarios and usage of external modules. They can be developed, debugged, and tested locally and managed using a command-line interface (CLI).
You can read more about FlexServices here.
Debugging using a debug UI is not available in Kinvey. In order to debug your code, you need to log to the console and then examine the log.
As mentioned above, FlexServices can also be tested and debugged locally.
In Kinvey, it is not possible to specify who can execute a custom endpoint. Still, it is possible to control this from your code.
The push notifications functionality in Kinvey is slightly different than in Telerik Platform. The main differences are stated below:
- No Windows support—Windows and Windows Phone are not supported in Kinvey
- No push from client—push notifications can only be sent through business logic or through the Kinvey Console (Web UI). The security policies available in Backend Services are not present out of the box; you need to implement them in business logic.
- User-based registrations—registrations for push notifications are based on user, not on device.
- No Devices browser—in Kinvey you do not have a UI-based browser for the registered devices and their attrubutes.
- No scheduling—it is not possible to schedule push notifications in Kinvey.
Kinvey provides native SDKs for various platforms as well as SDKs for multi-platform frameworks like NativeScript and Cordova. The table below lists the supported platforms and makes a comparison with Backend Services.
|Platform||Support in Telerik Platform||Support in Kinvey|
|.NET (Windows Phone)||yes||no|
|.NET (Windows 8)||yes||no|
Although SDK support looks very similar in both products, the Kinvey native SDKs are much more mature.
- Angular SDK
- Angular 2 SDK
|Feature||Support in Telerik Platform||Support in Kinvey|
|Offline Data Encryption||yes||yes|
|Push Notifications (Cordova/NativeScript)||yes||yes|
|Kendo UI integration||yes||yes|
The table below compares the .NET SDK features between Kinvey and Telerik Platform.
|Feature||Support in Telerik Platform||Support in Kinvey|
|Offline Data Encryption||no||yes|
|Push Notifications for Xamarin iOS and Xamarin Android||no||yes|
|Push Notifications for Windows||yes||no|
The Backend Services Administration API that allows managing your app through code is not available in Kinvey. Currently you have to made all administrative operations from the web console UI.
The feature for manipulating images is not available in Kinvey.
If you are using the Responsive Images service in Telerik Backend Services, you need to switch to a similar service from a third party.
Kinvey supports email notifications for the purposes of both user management and custom email messages.
The available options for email notifications regarding user account lifecycle management are listed here.
You can customize the look and feel of the received email.
Custom email notifications in Kinvey are not based on separetly-defined email templates. They are exposed from an available module in the Business Logic layer. This module can be used either from Collection Hooks or from a custom endpoint.
You can read more about how to trigger email notifications for the user account related operations from here.
You can learn how to use the module for sending customized email notifications with dynamic content from here.
In Kinvey, it is possible to have different environments for the same app (development, staging, live, etc.). This makes it easy to design and test improvements of your app without affecting your current customers.
After you are done with the changes, you can easily migrate them from one environment to another.
Kinvey Operational Intelligence is a service that provides analytics and usage information logs with the ability to create filters, study correlations, and visualize data, all with the goal to provide specific app insights based on the gathered analytics records.
For more information about the types of data available in Operational Intelligence, see the API reference.
Note, that this feature is included only in the highest subscription tier of Kinvey.
There are a number of deployment and regulatory compliance areas where Kinvey stands out to Backend Services.
With Telerik Backend Services, your backend always resides in the United States. With Kinvey, you can also chose to have your backend in Europe.
This can help if your customers are mostly in Europe, as the communication will be much faster. Also, having your data in Europe helps you achieve compliance with the EU directives for protection of personal data.
The Enterprise Kinvey license includes dedicated managed deployment of Kinvey, provisioned only for the use within your own organization.
This option was not available with Telerik Backend Services and is great for enterprises that are interested in the highest level of security, stability, and performance.
All the major cloud infrastructure providers are supported for your dedicated Kinvey instance. You can chose to have it on AWS, Azure, or GCP.
This way you will be able to easily and efficiently reuse other cloud services you use from your cloud provider.
As opposed to Telerik Backend Services, Kinvey offers a HIPAA compliant deployment option. This makes it even more suitable for healthcare-related apps and data.
You can read more about HIPAA compliance in Kinvey and its benefits here.