https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-...
"To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison."
Crazy engineering. They've rebuilt the internet (network layer and a browser) for their app...
The Lite client is a simple VM that provides various capabilities to
interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
On Wed, Mar 9, 2016 at 3:54 PM, Gilles Dubuc gilles@wikimedia.org wrote:
https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-...
"To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison."
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Yeah, this was a great read! Crazy engineering indeed!
We're not going to be implementing a custom networking protocol for our Android app anytime soon, but for me here are some of the key takeaways applicable to our app from what Facebook is doing:
-prioritizing keeping the APK slim -optimizing image size/quality -optimizing based on the specific "device year class https://code.facebook.com/posts/307478339448736/year-class-a-classification-system-for-android/" and network connection quality
-m.
On Thu, Mar 10, 2016 at 10:59 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
Crazy engineering. They've rebuilt the internet (network layer and a browser) for their app...
The Lite client is a simple VM that provides various capabilities to
interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
On Wed, Mar 9, 2016 at 3:54 PM, Gilles Dubuc gilles@wikimedia.org wrote:
https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-...
"To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison."
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
In my company around 2008-2010, all our servers and apps used a muxed connection over tcp, carrying protocol buffers, for many of the same reasons. We stepped away from that at some point, since http maintainability (more, simpler libs, easier debugging etc etc) + improved 3G connection speeds, simply no longer made that technology stack economically viable to maintain, but it was great technology and made those apps perform a lot better than the competition back then.
Good times.... and nice to see that the same basic principles still make sense if u have the money to invest into that.
DJ
On 10 mrt. 2016, at 16:59, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Crazy engineering. They've rebuilt the internet (network layer and a browser) for their app...
The Lite client is a simple VM that provides various capabilities to interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
On Wed, Mar 9, 2016 at 3:54 PM, Gilles Dubuc <gilles@wikimedia.org mailto:gilles@wikimedia.org> wrote: https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-... https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-for-every-android-phone-and-network
"To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison."
Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
These days, HTTP/2 does pretty much the same thing (efficient multiplexing over a single TLS stream). Ideas from https://en.wikipedia.org/wiki/QUIC might take it even further in HTTP/3.
On Thu, Mar 10, 2016 at 12:10 PM, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
In my company around 2008-2010, all our servers and apps used a muxed connection over tcp, carrying protocol buffers, for many of the same reasons. We stepped away from that at some point, since http maintainability (more, simpler libs, easier debugging etc etc) + improved 3G connection speeds, simply no longer made that technology stack economically viable to maintain, but it was great technology and made those apps perform a lot better than the competition back then.
Good times.... and nice to see that the same basic principles still make sense if u have the money to invest into that.
DJ
On 10 mrt. 2016, at 16:59, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Crazy engineering. They've rebuilt the internet (network layer and a browser) for their app...
The Lite client is a simple VM that provides various capabilities to interact with the OS (such as read a file, open the camera, create an SQLite database, and so on) and a rendering engine to drive the Android UI. Product code is written on the server and is expressed in terms of the capabilities the client has. Resources are sent down from the server as needed and cached. So it has infinite scalability for building additional product without bloating the APK.
On Wed, Mar 9, 2016 at 3:54 PM, Gilles Dubuc gilles@wikimedia.org wrote:
https://code.facebook.com/posts/1365439333482197/how-we-built-facebook-lite-...
"To achieve an extremely byte-efficient wire protocol, instead of using HTTPS, Lite uses a custom message protocol over TLS (directly over TCP). One of the biggest pain points in a 2G network is that establishing a connection can be very slow; it can take multiple seconds. As most Lite traffic flows over a single connection to the backend, this pain point is mitigated in comparison."
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l