Holy Grail! — The Experience API for Mobile Apps
You have to be careful when you talk about an API for driving a digital experience, because the words you use have different meanings to different people. Case in point: Experience API. In this article we’ll talk about the dream that is the Experience API in the context of mobile app development, and how it can dramatically improve the recoverability of your app and lower your development time and cost. Ok, so first of all…
What is an Experience API?
Depends who you ask, really. According to Chris Hood, the Head of Business Platform Strategy at Google Cloud, Experience APIs are:
APIs that innovate and target user experience (loyalty programs, profiles)
Now, that’s pretty broad, so we’re going to expand on it a bit, and talk about the ultimate dream of Experience APIs for mobile. But before we can do that, we have to talk about the different types of data your mobile app (probably) needs.
Data for Digital Experiences
In general, any digital experience that’s personalized in anyway to its users is going to have two generic buckets of data: User Data, and Content Data.
User Data is — you guessed it — data pertaining to an individual user. Usually this data is associated to the user and protected using credentials — user name and password.
This can be anything an individual enters into your product — Name, email, address, files, preferences, etc. This data is generally authenticated in some way, using the user’s credentials.
Content Data, on the other hand, is often unauthenticated, and not specific to any individual user. It can be images or strings of text for just about anything in the app — articles, error messages, notifications… even button labels. This data is specific to your app, and can vary based on use-cases, but isn’t tied to any individual user.
Sometimes, content and user data have to be mixed together in order to resolve the presentation to the user. For example, imagine a Todo List app, that has reminders. You want certain parts of the the reminder to be specific, and other parts are not:
In the reminder above, there’s some user data — the type of reminder (“massage”) and the date (Sat, Jan 4 2018). And some content (“Good news!, your {event-type} is scheduled for {date}”)
The work of getting these two types of data and combining them into what the user sees is called business logic, and it’s generally the job of any front-end digital product.
But, what if it weren’t?
Moving (some of) the Business Logic
In the world of mobile apps, we’re constantly talking about moving the business logic out of the app. Why? Well, there are always at least two apps — iOS and Android —maybe three, if you also have a web app. That means that all the logic has to be written, tested, and debugged two or three times. That’s three separate teams, doing three separate development activities, to achieve the same result, with three opportunities to screw it up.
Further, for mobile specifically, if you do screw it up, you have to do an application release in order to fix it. Mobile apps aren’t deployable, they have to be compiled into binaries and published. That means regression testing, branching, release prep, approvals, documentation — all the expensive red-tape around a large-scale mobile app release… just to correct a misspelled word. Anything that can potentially avoid the need for an app release will save you time and money. In addition, mobile app users don’t have to update to your new release if they don’t want to, so even if you go through all the time an effort to publish an update, an old, incorrect or out-of-date version of the app might always be out there.
The specific logic we’re talking about moving is the combination of static content with account-specific user data to create a fully-resolved data payload. Remember the notification example above? Instead of the app separately receiving some data about the user’s reminders, and the content that should go in the notification, as it normally would — the middleware would do that work and deliver the entire piece of content with all the substitutions already made.
The app doesn’t need to know how to compose the data from its parts, it just draws the text it’s given onto the screen verbatim.
How it Works
Cool, so we know what we want — the middleware to do all the work it possibly can — now we just need to know how to build it.
Basically, we want to build a smart, contextual API that knows what data and content to get, and how to combine them. The context of the request is determined both by the request itself, and the orchestration layer.
Orchestration
In the orchestration step, the request is dismantled in order to figure out what data is needed in order to respond. The request might contain user account info, like an authorization token, so that we can identify the user. It will have have a unique path and method, telling us what the user wants to do (i.e. GET, POST) and what result they want (i.e. GET /todolist). Now the orchestration layer can do its work.
First it would send the token to some authentication micro-service to be decoded, and get the user’s ID. Then it might take the ID and lookup the user’s stored to-do list. And finally, the orchestration layer knows that it will need to combine that raw data with some content, in order to render a readable list, so it then goes out to our CDN and fetches the todo list content. This is where our system shines over others. Normally, this is the step the application would have to do. With this step moved to the cloud, the content and data we use for this request can be changed at any time, and then deployed, without any application development or release.
Presentation Logic
The next step is presentation logic: combining the data and the content into a user-consumable format. Again, these rules would normally be executed on the front end client, requiring an app release to change. By moving this logic into the API, we sidestep this requirement. In the presentation layer, the data and content are received from orchestration, and a set of business rules are executed to produce the fully-resolved payload that the app will put on the screen. Once again, this logic can be changed and deployed at any time without an app release.
Caveat: Speed
One thing I frequently hear is that the response from an API that does all this work is just going to take too long to return, and mobile app users are impatient. While the latter is definitely true, consider this about the former: you have to do all of this work anyway, and your cloud infrastructure is always going to be much faster than your mobile phone. The only real bottleneck here is your network speed. And that would still be a problem doing things the old fashioned way.
The Value
If I’ve said it once, I’ve said it a million times: App Release are expensive. They require lots of testing, approvals, sign off, certifications, and other red-tape to wade through to get to users. In addition to the time and money you’ll save by not doing releases, you also write less code, and the logic that powers your experiences all lives in one place. Update it once, every platforms gets it for free.
The Absurd Conclusion
Once you start down the rabbit hole, things can get as complex as you want. The pie-in-the-sky endgame of this might be that the app become a native renderer for components that are fully spec’d with data, content, design and even functionality through the Experience API. This would essentially turn your app into a fully-native browser, but instead of rendering HTML, it would render native UIs, based entirely on deployable resources.
A true hybrid app, but with none of the drawbacks…
