Database-Drive UI - Database-driven Logic
Rather than managing dozens of independent features and having each pull information and build its own cache on the app, we leveraged the SQLite database as a universal system to support all the features.
Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000.
We accomplished this by using the native OS wherever possible, reusing the UI with dynamic templates powered by SQLite, using SQLite as a universal system, and building a server broker to operate as a universal gateway between Messenger and its server features.
Native Code
When building a new feature, it’s often tempting to build abstractions on top of the OS to plug a functionality gap, add engineering flexibility, or create cross-platform user experiences. But the existing OS often does much of what’s needed. Actions like rendering, transcoding, threading, and logging can all be handled by the OS. Even when there is a custom solution that might be faster for local metrics, we use the OS to optimize for global metrics.
While UI frameworks can be powerful and increase developer productivity, they require constant upkeep and maintenance to keep up with the ever-changing mobile OS landscape. Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs.
Push Logic to the Server
For anything that doesn’t fit into one of the categories above, we push it to the server instead.
In today’s Messenger, we have a universal flexible sync system that allows the server to define and implement business and sync logic and ensures that all interactions between the client and the server are uniform.
https://engineering.fb.com/data-infrastructure/messenger/
Rather than managing dozens of independent features and having each pull information and build its own cache on the app, we leveraged the SQLite database as a universal system to support all the features.
Compared with the previous iOS version, this new Messenger is twice as fast to start and is one-fourth the size. We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000.
We accomplished this by using the native OS wherever possible, reusing the UI with dynamic templates powered by SQLite, using SQLite as a universal system, and building a server broker to operate as a universal gateway between Messenger and its server features.
Native Code
When building a new feature, it’s often tempting to build abstractions on top of the OS to plug a functionality gap, add engineering flexibility, or create cross-platform user experiences. But the existing OS often does much of what’s needed. Actions like rendering, transcoding, threading, and logging can all be handled by the OS. Even when there is a custom solution that might be faster for local metrics, we use the OS to optimize for global metrics.
While UI frameworks can be powerful and increase developer productivity, they require constant upkeep and maintenance to keep up with the ever-changing mobile OS landscape. Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs.
Push Logic to the Server
For anything that doesn’t fit into one of the categories above, we push it to the server instead.
In today’s Messenger, we have a universal flexible sync system that allows the server to define and implement business and sync logic and ensures that all interactions between the client and the server are uniform.
https://engineering.fb.com/data-infrastructure/messenger/
Comments
Post a Comment