App thinning slicing and on-demand resources


#1

As my application and user base grows in size and numbers, I can see a point where some of my clients might not need ever feature my application can/will provide.

For example, maybe one client makes use of features a, b, c, and another doesn’t use a, b, c, but x, y, z.

I don’t like the idea of composing my application as a set of packages.

Then I came across a very long article about the new Apple TV and the way Apple is changing the way the development of that platform delivers applications to the device.

TL;DR; Apple is making ‘App Thinning’ mandatory for the new Apple TV (it’s available for the iOS, but optional). Apparently App Thinning allows the use of ‘tags’ to indicate what resources are related. The client only gets what it needs to start, and as the user traverses the application, the server will send down what the client needs. If the client requests feature a, b, c, the server will push down these features and if feature b needs a particular code set, through ‘tag’ relationships, the server will download just what is needed.

Applying these principles to Meteor, this would be an amazing way send the client just what it needs, keep it as light as possible, and saving server resources too.

Further it seems like a something like this could be a strategic advantage for Meteor over say the Facebook stack.