Development of new versions of an app with Backend Services

[Paul]

Hi there

I am looking at developing a mobile app that uses Baas and I can see that it offers everything that I need and I can easily develop version 1 of my app with data stored on Telerik Backend Services.

However, what I can find any information about is to how we then proceed to develop version 2 of the app bearing in mind that version 2 will more than likely require data changes on the backend services. In my current web development world version 2 of a product would be developed using a separate database. When version 2 is ready to be deployed I would run a set of update scripts for updating the version 1 dataset to version 2 and then deploy the version 2 software.

My general questions therefore are:

1. How to you define version 2 of the app and start developing that without affecting version 1 and users of the version 1 app?

2. Is it possible to set up a sandboxed test data set area on the backend services once an app is live for continued development of version 2 of the app?

3. How do you rollout the changes to the version 1 dataset and app for version 2 when version 2 is ready to be deployed?

This is all basic development stuff but I can't see any discussion of how this is achieved with AppBuilder and the Backend Services.

 

Thanks for any help.

Regards

Paul Marsden

[Anton Dobrev]

Hi Paul,

Thank you for posting to the Telerik Developer Forums.

You may consider creating a separate app in Telerik Platform for development purposes that will hold the new Data, Users, etc. When this database is ready for production, you may want to update the App Id in the app code to point to the new app database or extend the production database by adding into it the new types and data from the development database.

Some further suggestions to consider when creating the workflow that best works for your requirements.

You may visit the articles in the Administration API and the Access Control section to learn how to programmatically create types and other administration and access control operations.

One thing to consider is that accounts in the Users system type from a given databases cannot be integrated into another database.

In addition, may I suggest that you first test on your side the way the REST API works, for example, using tools like Postman, Fiddler, Charles, Paw (the last two are Mac-only) and the specified headers to familiarize with the way the data is stored and retrieved from the database, how permissions work, etc. 

In your code you can have a specific environment settings which you may also find useful. 

In regard to version control of your code you may explore the version control options here.

Let me know if this answers your questions.

Regards,
Anton Dobrev
Telerik

 

 

[Paul]

Hello Anton

Thank you for your reply.

Can you explain how I would go about the following upgrade then?

1. Develop v1 of an app using backend services with a number of types and users that logon and own some of the types.

2. Put v1 live and allow users to register and use the backend services.

3. Create a test v2 app with a new database and users and test. v2 will be based on v1 but will involve updates and changes to the types in the database, perhaps new relationships etc.

4. At this point I want to upgrade the v1 app and database to the same as v2 and roll it out to all users.

Am I to understand that this is not possible or that I would need to write some sort of migration code using the REST API's of my own to take data from the v1 database to the v2 database? If this is the case how would you handle the migration of the users from v1 to v2 database.

Sorry to be a pest but this sounds like it would be very painful upgrading. There must be a better way than this or am I missing something.

 

Regards

Paul

[Lyubomir Dokov]

Hi Paul,

Changing the data model (API) of a live app is always a tough task to accomplish. With mobile apps you cannot rely that everyone will upgrade to the latest version immediately (if at all).

One way to proceed with such a significant change is this:

1. Make your changes to the data model in an isolated environment(database), different than the one that your live app uses.
2. Make certain the old mobile app works well with the new data model, if necessary insert some server-side logic to handle old requests to the new data model.
3. Adjust the code of the mobile app to use the new data model.
4. Apply the new data model to the live environment.
5. Release the adjusted mobile app to the marketplace.
6. With time you will be able to remove the server logic that handles requests from old versions of the app, once everyone upgrades.

I know the above is not easy to accomplish and is error prone. Depending on your requirements, you could go a different path:

1. Whenever the app starts, ask the server for a minimum client version it supports. If the current version is less than the minimum version of the server, require the user to update the app.
2. Make your changes to the data model in an isolated environment(database), different than the one that your live app uses.
3. Adjust the code of the mobile app to support the new data model, but keep it compatible with the old model.
4. Release the adjusted mobile app to the marketplace.
5. Set the minimum client version to be the version of the newly released app.
6. Apply the new data model to the live environment.
7. Remove all compatibility code in the mobile app.

We are currently thinking on how we can improve the process of releasing a new version of an app in the Telerik Platform. As Anton mentioned, there is an administrative API you can use to automate some parts of the process. Currently, there is nothing out-of-the-box you can use.

I would love to read your opinion on all this. Are the scenarios I described above similar to what you have in mind, or your process will be different? What functionality would you expect to make this process easier?

We are thinking about providing a staging environment, where you could test changes and then apply them to the live app. Also, we are investigating if we could somehow provide custom API versioning, so that you could have more than one version of your API(data model) available at the same time.

In any case, for more advanced apps that may require significant changes of the API, I suggest the following:

1. Implement a way to get supported client version from the server (for example, via a Cloud Function in Backend Services). Check for this version in the mobile app and require update, if necessary. If you do this from the start, it might make your life a lot easier later.
2. Plan for downtime - I know it does not sound like something you want to have, but if you have a really big change in the data model, you might need some time for transferring data from the old model to the new one. Again, a simple IsInMaintenance cloud function that returns true or false might save you a lot of trouble.

Please let me know what you think, I would be happy to discuss this further.


Regards,

Lyubomir Dokov
Telerik