Exploring patterns around Data Driven Apps

A few years ago, I was a part of a project in which we were tasked with making a few cross platform mobile apps using Xamarin. These would be quick and dirty PoCs (proof-of-concept) for some of our enterprise customers from different industry verticals. We thought of reusing as much code and assets as we could. That was my first experiment with data driven apps.

Data Driven Apps

Before I go into details, I would like to elaborate a bit on what I mean by data driven apps. In general, almost all the apps do some sort of state or data management. The user data, the app’s state, the preferences, the configuration, etc. are stored somewhere as data objects. More than often, this storage is a distributed database sitting in the cloud behind an API which serves data to the apps on mobile/web clients. But this is not what I mean by data driven apps.

What I mean by data driven apps is when the behavior of the apps is also driven by data. In the above mentioned example, it’s mostly the state of the app being stored. Most of the business logic and behavior of the app is still sitting on the client, packaged in the app.

Let’s take an example to make things clear — consider a point of sales app for a bank. The primary user of the app is a salesman who carries a tablet device and gets new users/clients registered for bank’s services (accounts, insurance, etc.) using this app. The registration process has a workflow with several steps including filling up a form, uploading a photo, capturing the signature, etc. There can be two approaches for creating this point of sales app,

1. The conventional approach — Package the business logic, validation rules, and the UI elements in the app. When a new registration flow is initiated, record all the information through a form in the UI and call a service to post the registration form data. The service endpoint is also read from a configuration file packaged in the app. This is how most of the apps are created today.

2. The data driven approach — The app package does not have all the business logic in the code. When a new registration flow is initiated on the app, assuming the cache is empty, the app fetches the number of steps in the process, the fields in the registration form and their placeholder values, the validation rules, etc., and generates a dynamic UI for the user. The UI templates on the app are expected to be inline with the data being served else there would be an app update needed. The app can cache most of this data at regular intervals to save bandwidth and to work in offline scenarios. Following is a simple representation of this data in JSON format.

{  
    "registration_steps": [  
        {  
            "name": "basic_details",  
            "fields": [  
                {  
                    "key": "first name",  
                    "placeholder": "john"  
                },  
                {  
                    "key": "last name",  
                    "placeholder": "doe"  
                }  
            ]  
        },  
        {  
            "name": "family_details",  
            "fields": [  
                {  
                    "key": "married",  
                    "placeholder": "no"  
                },  
                {  
                    "key": "children",  
                    "placeholder": "no"  
                }  
            ]  
        }  
    ],  
    "validation_rules": [  
        {  
            "condition": "basic_details.first_name.is_empty",  
            "rule": "disable submit"  
        }  
    ]  
}

There are clear differences between the two approaches. The first one isn’t as dynamic as the other and that’s the difference I am talking about when I say data driven apps.

Data Driven App Patterns

Through my projects and experiences, I’ve come across following patterns when designing and developing data driven apps.

Dynamic Configuration — Level 1

Dynamic configuration is the very basic type or level 1 of data driven apps. In this case, the apps have all the business logic and UX still packaged in them but the configuration is dynamic. The app loads the UI as per the configuration received from the server. The primary use case of these apps is when the UI which can be reused across multiple scenarios. Imagine a catalog app showing list of items. It could be a list of restaurants, places, products, people, etc. When the app calls the data API, the app is served with the data along with the configuration and this configuration defines how the app binds data with UI. After all it’s just a list with metadata for items and the UI template being used is expected to render lists.

For quick and dirty PoCs and MVPs, this approach can lead to faster development.

Data Driven UI — Level 2

The next level for data driven apps is data driven UI. These are primarily for use cases like the one I described above for the banking point of sales app — when the registration steps can change based on the location. In this case the app renders dynamic UI leading to a different experience for the users. This comes in very handy when we want to drive different processes through the same app and these processes share the basic UI flow but not entirely.

Data Driven Business logic — Level 3

Data driven business logic is the next level where we have advanced use cases of rules and logic being served dynamically. Business logic is basically stored as data in if...this, then...that format and it is inferred by the code in the app as a list of rules in a specific order. The order is also driven by data, by the way. The primary use case for this type of apps is when we have different set of rules being run on same type of objects under different conditions. The outcome of these rules may or may not result in a different UI of the app. Data driven business logic is basically useful in scenarios when the business logic needs to be updated too frequently. Let’s say an app having some rules and calculations based on stock prices (yeah, I couldn’t think of anything more dynamic). These apps are hard to design because once the app is packaged and distributed and if things go wrong then there is not much we can do except pushing major updates. By design I mean — how the code and the data driven rules would integrate; how much room would be there for changing and updating rules on the fly, etc, etc. But once the app is designed properly, then, I believe, this is the most elegant thing we can do with app development.

Blockchain

Imagine a scenario where the app’s data, business logic and configuration is being served by a blockchain. This could be the level 4 of data driven apps where the data is fully secure and tamper proof and also not being controlled by any centralized providers (app stores). The app could connect to any of the blockchain nodes when roaming, reducing overall latency.

We did some similar experiments on web apps where we kept the authorization rules on the blockchain as data assets and then the clients interacted directly with the blockchain (and the data) using these authorization rules. I believe, blockchains bring a whole new and exciting angle to data driven apps.

Well, that’s what I wanted to share about my experiences and experiments with data driven apps. Some of these ideas have really helped us in shipping quality code in record time. We just need to be a bit more careful because dynamism introduces vulnerabilities and exposes attack surfaces and they should be dealt with before releasing the bits.