Where Should the Brain of Your Mobile Application Live?

Transcription

1 Where Should the Brain of Your Mobile Application Live? Or, how Gilt architected its ios apps so compiled binaries released years ago can keep up with evolving server data models

2 First, an introduction

3 >9 million active members Ships 22,000 packages/day to over 100 countries Works with >6,000 brands and >4,500 local vendors Once sold a $60,000 round-trip private charter of an entire Virgin America plane in 11 seconds with over 1,100 people signing up for a waitlist in case we ever re-ran the sale!

4

5 Mobile >50% of Gilt s revenue comes through Mobile channels, which includes native apps on ios and Android, and mobile web >10 million app downloads Fastest checkout was 0.2 seconds (a Volkswagen Jetta sold through the iphone app) Most expensive item: $29,603 for the 2014 Acura MDX with an L.A. travel package (via iphone app)

6

7 Evan Maloney Distinguished Engineer Engineer on Mobile team since 2010; responsible for ios core platform Prior to Gilt, created first versions of the Reuters News Pro ios apps Steve Jobs had at least one of my apps installed on his iphone Despite title, my job does not involve wearing a top hat and monacle

8 What we ll discuss

9 I. The Legacy App Version Problem App versions released years ago are still in use, and you want to support those users. But you also need to evolve your server environment. You can t force those users to update, what do you do?

10 II. Strategies for Addressing the Problem (A) Through an Ever-Growing Proliferation of Service Versions Every incompatible service change results in one of the following: Forking the codebase and maintaining legacy versions of the affected services Operating a single service with an increasingly complex nest of client capability checks in the code

11 II. Strategies for Addressing the Problem (B) By Adopting Web-style UI in your application This strategy involves building a native app where some or all of the user interface is presented in web views: The UI is served to the app just like regular web pages, so it is always up-to-date In extreme cases, the entire app is just a native shell around a mobile website

12 III. How We Thought About This at Gilt We realized the root of the problem involved how app developers assigned responsibility between the client and the server: For example, standard app architecture requires both the client and the server to have code that understands the format of the data used between the two But what if it didn t have to be that way? What if the server could tell the client how to extract meaningful information from the data models it serves? Services could evolve without breaking compatibility with existing apps

13 I. The Legacy App Version Problem

14 The only constant is change Gilt s backend web services support sales via desktop web, mobile web, and iphone, ipad & Android apps Software for these channels are all under active development by different teams Over time, various technical and business requirements have resulted in breaking changes needing to be made to the backend services

15 The Root of the Problem The client app and the server must always agree on the structure of the data On the client side, this knowledge has to be compiled in to the application binary Once an app binary has been installed on a device, it can t be modified by the vendor

16 How are others addressing this?

17 Multiple Service Versions Running multiple service versions is a common strategy, but that comes with some costs: The existence of multiple versions increases maintenance costs, and makes it harder to evolve the server stack Sometimes, you need to retire an old service because it costs too much to operate, so needing to maintain a legacy version defeats the purpose

18 Web-Based UI A more extreme solution is to move some or all of your app s UI to web views that frame your mobile website Write-once, run-everywhere has always been the unattainable holy grail of software development, but there s a reason people write native apps just ask Facebook! Can be a useful technique when used judiciously at Gilt, we use it for the privacy policy and terms & conditions copy

19 Mul$ple service versions Adop$ng a web- based UI Pros Don t need to do any work for already- released apps; they ll just con$nue to work Immediate release, no app review Exis$ng versions are updated without requiring a new binary to be downloaded & installed Not much na$ve development, which can be expensive Cons High long- term maintenance costs Ties you to an old so@ware stack; hinders evolu$on of your systems Doesn t address case where a business needs to re$re a service A lowest- common- denominator user experience that doesn t quite feel right on any plamorm Lack of control over memory management & concurrency means that a complex UI with lots of assets won t perform well at scale No direct access to hardware

20 Implications Server- side Client- side Mul+ple service versions Increased complexity and maintenance costs None Client can be freely updated over 3me Adop+ng a web- based UI None A free- ride off your exis3ng mobile website An inferior user experience, client- side performance doesn t scale

21 For some use-cases, these are acceptable trade-offs

22 but they weren t for Gilt.

23 So, how did we address it?

24 How most server-driven apps are built 1. The server maintains knowledge of the data necessary to drive the app 2. The app requests data, and receives a data structure in response 3. Because the app needs to ask questions of the data, developers usually hard-code knowledge of that data structure into the app

25 How server-driven apps could be built 1. The server maintains knowledge of the data necessary to drive the app 2. The app requests data, and receives in response: The data itself Instructions for how to extract relevant values from that data 3. The app will still ask questions of the data to do its work, but it will use server-provided instructions to do so

26 TA-DA! The client no longer needs advance knowledge of the server s data model!

27 We call this model/query decoupling, but it s really just a different way of thinking about where you hard-code knowledge.

28 Model/query decoupling is achieved when: The ability to query a set of data does not require direct knowledge of that data s structure

29 Typical knowledge responsibility breakdown The Client App needs to know: 1. The exact structure of the data The Server needs to know: 1. The exact structure of the data 2. What ques$ons it needs answered from the data 3. How to translate those ques$ons into procedures for extrac$ng answers from the data

30 Breakdown with model/query decoupling The Client App needs to know: 1. What ques$ons it needs answered from the data The Server needs to know: 1. The exact structure of the data 2. The set of ques$ons each app version needs answered from the data 3. How to translate those ques$ons into procedures for extrac$ng answers from the data

31 Breakdown with model/query decoupling The Client App needs to know: 1. What ques$ons it needs answered from the data The Server needs to know: 1. The exact structure of the data 2. The set of ques$ons each app version needs answered from the data 3. How to translate those ques+ons into procedures for extrac+ng answers from the data

32 How do we do this at Gilt? 1. We created an ios framework called the Mockingbird Data Environment that allows us to construct plaintext expressions that can be used to navigate, transform and extract data from arbitrary data models 2. In addition to sending data, our servers send expressions that allow our apps to extract meaningful information from that data 3. When we change our data model, our servers send an updated set of expressions, which legacy versions can then use to extract information from the new data model

33 How do we do this at Gilt? 4. Our app asks our data questions like, What sales are there today? and How many items of this SKU are available? 5. For each such question, a corresponding Mockingbird expression can be created to return an answer in whatever format is expected by the app 6. When the app needs to know, say, What products are in this sale?, it uses the most recent version of the Mockingbird expression associated with that question, and evaluates it, yielding the result in a format the app understands

34 How does it work? Once the app is released, the format of the data that it needs to populate the user interface can no longer be changed However, the underlying server data model can be changed because the app never interacts with it directly The app uses Mockingbird expressions to translate between the server model and the data format expected by the compiled UI Because we can update the expressions, we can change the data model

35 The result Allows for fully native user interface Total flexibility over changing backend whenever you need Legacy app versions will still work Don t need to wait for app review or the user s upgrade cycle Users who can t upgrade to your latest version due to hardware or OS requirements will still be supported

36 The underlying philosophy

37 Let the server dictate the terms of server-y things Let the client dictate the terms of client-y things

38 One more thing

39 You can use the same code Gilt uses to do this, and add it to your own ios apps for free. Gilt has open-sourced the Mockingbird Data Environment: Available under the MIT license, fully documented & ready to use!

40 Where Should the Brain of Your Mobile Application Live? Evan Maloney Distinguished Engineer Gilt Mobile