
LightSpeed: Rewriting Messenger’s codebase for a faster, smaller, simpler app - moneil971
https://engineering.fb.com/data-infrastructure/messenger/
======
butz
The loop of app building: 1\. Build app with native framework. 2\. Re-build
app with some alternative framework which is slower, but let's you deploy
single code on all platforms. 3\. Re-build app with native framework, because
it is faster. 4\. GOTO 2

~~~
nneonneo
The best part about this cycle is that developers can always point to some
metric which shows improvement to justify their actions, resulting in an
Escher-like loop where they think they’re always going up.

These cycles pop up all the time in development as priorities shift (or as
developers find more excuses to “fix” what isn’t broken). Real world coding
always involves compromise - leadership is recognizing which compromises to
make without continually backpedaling.

~~~
lord_braleigh
To be fair, small fast messenger 2020 _is_ "better" (aka more features /
millisecond of cold start) than small fast messenger 2016. The cycle doesn't
always go up monotonically, even if developers pretend it does. But it is
possible to go "full-circle" through the loop and wind up in a better place
than you started, and it's even possible for each stage of the loop to be
truly justified given product needs.

~~~
joshspankit
How much of that is simply improvement in processing speed of the device
and/or better OS APIs?

------
millstone
From [https://engineering.fb.com/data-
infrastructure/messenger/](https://engineering.fb.com/data-
infrastructure/messenger/):

 _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.
This reduced not only size, by avoiding the need to cache /load large custom-
built frameworks, but also complexity. The native frameworks don’t have to be
translated into sub-frameworks. We also used quite a few of the OS libraries,
including the JSON processing library, rather than building and storing our
own libraries in the codebase._

This is awesome. It shows the benefits of building an app leveraging the OS,
instead of fighting or abstracting it.

~~~
reaperducer
They make it sound like the clouds parted and a ray of sunshine struck the
programmers at Facebook and they realized that they didn't have to ride the
framework-go-round to hell.

These are supposed to be the smartest people in SV, but from the outside, it
strikes me more as a "No shit, Sherlock" moment.

~~~
karatestomp
Which, for example, gets you more sway with your employer, personal "branding"
value, and future income / ease of switching jobs: "I was instrumental in
inventing React" versus "I was instrumental in realizing we didn't need to
invent React"?

~~~
saagarjha
“I was instrumental in making Messenger twice as fast?”

~~~
karatestomp
Well yeah, but first someone has to get the credit for creating some "high-
productivity" hog of a framework to make it slow, _then_ someone else can come
tear all that crap out and claim they made it fast.

~~~
bobbylarrybobby
Why not be both people? "I made React _and_ I made Messenger twice as fast [by
ditching it]"

~~~
jjn2009
because that sentence can be read within the time span of human attention span
and the problem with it easily identified.

------
danabramov
Quite a few comments seem to imply Messenger was written in React Native, so I
want to clarify this is not true. Messenger was a fully native app before the
rewrite, too!

RN isn’t the right tradeoff for Messenger — whose new core is written in plain
C — but its use at FB in general is growing, with 750+ screens in RN. So the
rumours of its death are greatly exaggerated.

I think it’s great to have different options with different tradeoffs
available to choose from. But hey, that’s just me.

~~~
crtlaltdel
tweet thread by dan on the subject:
[https://twitter.com/dan_abramov/status/1234801507805138945?s...](https://twitter.com/dan_abramov/status/1234801507805138945?s=21)

------
aldanor
So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment:

\- NumPy is 360K lines mostly C

\- Postgres is around 2.1M of C

\- Go 1.13 is around 1.5M of Go code

\- Rust 1.37 is around 1.2M of Rust code iirc

\- core llvm is around 3M of C++ iirc

...

A chat app is 1.7M. A chat app...

Makes me feel sorry for all the time spent/wasted by all those devs, many of
whom are unquestionably brilliant and could've worked together on something
truly awesome, big and useful. But we all know that doesn't pay the bills and
so here we are.

~~~
lwb
Honestly, a chat app that 1 billion+ use per month that includes payments,
camera effects, extensive social integrations, stories, GIFs, reactions,
games, polls, voice recording, calling, video chat, and works across all
mobile platforms, with nine years of technical debt, that thousands of
developers build simultaneously seems WAY more complicated to me than any of
your examples.

Messenger may not have "HN clout" but the devs who work on it are having some
of the greatest software impact in the world.

~~~
_bxg1
> that includes payments, camera effects, extensive social integrations,
> stories, GIFs, reactions, games, polls, voice recording, calling, video chat

To be fair, this is part of the problem ^

~~~
threeseed
Just because there are features that you don't use doesn't make it a problem.

In fact people who like stories and camera effects likely way outnumber the
people that don't.

~~~
Aeolun
I strongly doubt that. The number of people in my list of friends (400ish)
that use stories is marginal.

The number of people that use camera effects as anything other than a gimmick
is even smaller.

Maybe a different age group?

~~~
golergka
> my list of friends

I think that most of people of HN have friend groups which are wildly
unrepresentative of world population at large. We're talking not even an
average US or European citizen here - we're talking 1+ billion. People from
developing countries who very often access internet only from a smartphone
(they don't own a computer) and who almost don't visit plain http websites
outside of the few social apps.

It's a completely different world out there.

------
reggieband
From: [https://engineering.fb.com/data-
infrastructure/messenger/](https://engineering.fb.com/data-
infrastructure/messenger/)

> We accomplished this by using the native OS wherever possible

Does this mean this application does not use React Native?

~~~
bmj
Yeah, that's how I am reading that.

Given the headaches caused by Apple finally barring UIWebView (the basis of
frameworks like Cordova) from new App Store submissions beginning in April,
I'm not surprised FB would do this. There is plenty of rumor-mongering that
Apple is going to make it increasingly difficult for apps based on hybrid
frameworks through the submission process.

~~~
Klonoar
UIWebView was deprecated for years, everyone's had plenty of time to move to
WKWebView, and it has nothing to do with React Native to boot.

Apple legitimately doesn't seem to care about hybrid frameworks, they've been
there since day one. Any time it's seemed like it got difficult Apple has
backed down. The lack of JIT in WKWebView is probably the only thing that you
could stretch here.

~~~
saagarjha
WKWebView is out-of-process and has a JIT.

~~~
Klonoar
Ah, you're correct - not sure why I thought otherwise, especially when I touch
WKWebView pretty often.

~~~
saagarjha
Perhaps you confused it with JavaScriptCore?

~~~
Klonoar
Hmmm, possibly. Either way thanks for the catch!

------
currysausage
"We started with the premise that Messenger needed to be a simple, lightweight
utility. Some apps are immersive (video streaming, gaming); people spend hours
using them. Those apps take up a lot of storage space, battery time, etc., and
the trade-off makes sense. But messages are just tiny snippets of text that
take less than a second to send. Fundamentally, a messaging app should be one
of the smallest, lightest-weight apps on your phone. With that principle in
mind, we began looking at the right way to make our iOS app significantly
smaller."

This paragraph just restored my faith in developer sanity.

------
jascii
Old joke:

Every program can be (memory)optimized by at least one byte and has at least
one bug in it.

It therefore follows that every program can be reduced to a single byte that
doesn't work.

------
dean177
> We extended SQLite with the capability of stored procedures, allowing
> Messenger feature developers to write portable, database-oriented business
> logic

I wish the article was a little more fleshed out, I'd be interested in finding
out more about how and why they went down this path

~~~
kreetx
I just listened to the Changelog's (a podcast) episode with Richard Hipp, the
author of SQLite -- I wonder if he had any part on this extension. But in any
case, great to see SQLite thrive.

~~~
SQLite
I did not. This is the first I've heard of it.

~~~
Legogris
I have to ask, did they pay the 6k license fee yet?

~~~
tbodt
I suspect they paid for the 85k/year support package

------
vodkaPong
The architecture they have ended up with is similar to that described in Out
of the Tar Pit, which describes how to remove as much complexity from software
as possible.

By moving all state into SQLite they have implemented the "store state in
relations" layer, and then written (as far as possible) functional code on
top.

I've been thinking about how to make my software more like this so it's
interesting to see Facebook are thinking along the same lines.

There's a lot of really good ideas in Out of the Tar Pit and I'd really
recommend reading it.

~~~
anthonybullard
I'll be reading this know. Thanks for the rec!

------
gagabity
Keep seeing react native pop up in the comments, there has never been any
indication that Messenger used any react native from fb feom all their
presentations I have see . RN is used in the Marketplace tab on the Facebook
App, the Ad manager app and a few other places.

~~~
danabramov
This is correct. The old Messenger app is 100% native.

------
monocasa
Considering that they were shipping 18,000 classes in their iOS app back in
2015, a quarter the size of their 2019 app has to be still unreasonably
massive.

[https://gist.github.com/quellish/473f513fbd1310233a8e](https://gist.github.com/quellish/473f513fbd1310233a8e)

~~~
LennyWhiteJr
The number of classes isn't necessarily indicative of the size or complexity
of an app.

~~~
monocasa
> The number of classes isn't necessarily indicative of the size

Size, not necessarily, but yes it was in the case (the person was looking at
why the binary itself, not any of the assets was above 100 meg).

> or complexity of an app

I'm not sure how 18,000 classes isn't a guaranteed extremely complex app.

------
WhyNotHugo
I don't know anyone who uses Messenger, yet, I've heard of people moving to
specific countries where it's the de facto and you can't have a social life
without it.

I'm also aware of how iMessages and SMS are used in the US, yet this is very
US-specific, and I don't believe any other country uses SMS.

For Chinese people, WeChat is the standard, and what pretty much anyone uses.

In Argentina and the Netherlands (and I believe much of the EU), WhatsApp is
ubiquitous.

Yet, I don't know a single person who uses either SMS or Messenger, or
iMessages.

So what truly fascinates me, is how different companies put so much work into
developing such sophisticated messaging apps, but they're all reinventing the
wheel and each consumed in different regions -- I think nobody would have
guesses years ago that we'd have so many different apps used in different
countries, and not at all inter-operating with each other.

~~~
jianshen
Did you ever use AIM, ICQ, MSN, Y! Messenger? I'm quite certain that in a
decade, there will be another batch of dominant messengers "reinventing the
wheel" (IG & TikTok I'm looking at you). Real-time Communication is just such
a crucial part of people's lives that people will never stop working on it,
even if it feels like it's been solved.

~~~
WhyNotHugo
I get chat these things evolve, and change over time.

My fascination is that we've very equivalent things (eg: WhatsApp and Telegram
aren't that far apart), duplicated even in the same generation.

I did use ICQ, MSN, IRC then WhatsApp, but they didn't belong to the same
periods.

------
AWebOfBrown
I thought Messenger was ReasonML's flagship use-case inside Facebook. If so,
it will be interesting to know what impact this has on its development.

~~~
dmitriid
Web only. However, there haven't been any updates on that for over two years
[1]

[1]
[https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...](https://reasonml.github.io/blog/2017/09/08/messenger-50-reason)

------
jconley
This is an interesting business decision. To rewrite such a large app must
have cost a fortune. Going full native is probably going to increase the cost
of future development as well. Aside from the costs of writing/maintaining the
code, pushing more work to the servers is an ongoing cost. Realtime, always-
connected, apps are costly to run even when you push the majority of the state
management to the client and just route packets around. They must really want
eyeballs in their messenger app! There must be some future plans for this app
that warranted such a major effort. Taking on Tik-Tok, perhaps?

~~~
jcelerier
> To rewrite such a large app must have cost a fortune. Going full native is
> probably going to increase the cost of future development as well.

it's a freakin chat app, and it's freaking facebook ! come on, people were
doing full rewrites in entirely different languages of software insanely more
complex than fb messenger back in the 90s and with near-zero tooling, eg from
cobol to pascal to C or similar horrors.

~~~
jconley
I've built a few "chat apps". I wouldn't discount the complexity. They carry
with them a wide array of problem spaces. And of course anything at FB scale
user counts is going to be a challenge.

~~~
Turing_Machine
While I have absolutely no doubt there are scalability problems, it seems to
me that most of those problems are going to be (or should be) on the back end,
not in the client. How is the _client_ 1.7 _million_ lines of code?

~~~
jconley
I can see it. It's pretty easy to hit that much code when you include your own
code for things as trivial as a JSON parser rather than leveraging what the
native SDK provides (which was alluded to in the article). It sounds like they
had a bit of Not Invented Here syndrome going on and this rewrite addressed a
lot of that. It also sounds like they had a bunch of systems (probably
different teams even) doing similar tasks like synchronizing state. And they
also had their own UI framework. All that stuff adds up to a lot of code. But,
all that being said, it still has a ton of features. It's not your father's
IRC client sending text around and failing to transfer files through
NAT/firewalls.

~~~
Turing_Machine
> But, all that being said, it still has a ton of features. It's not your
> father's IRC client sending text around and failing to transfer files
> through NAT/firewalls.

Meh. It displays text, pictures, and videos. That's about it. This is just
Messenger we're talking about here, not the full-blown Facebook app. The only
state to keep track of is "Have you received message UUID?".

> And they also had their own UI framework.

This is where I suspect the bloat occurred.

Writing your own JSON parser and so on doesn't add up to any 1.7 million lines
of code.

~~~
ex3ndr
Dont underestimate complexity.

For android you have to ship basically ffmpeg for correct mp4 encoding, on all
platforms you have to carry some library on top of classical ui framework to
make it just not suck at performance, you have to get your own json parser,
yes, since built-in one will be 10x slower, you may be want to carry even low
level QUIC library for networking and websockets, etc, etc.

All this also not increasing complexity since built in one stuff makes your
code much harder to read/write.

~~~
jcelerier
> For android you have to ship basically ffmpeg for correct mp4 encoding

hopefully they aren't counting ffmpeg in their LOC count, right ? else they
may as well count the lines of code of the C and C++ standard library, V8, etc
- this would be a very useless metric

------
benbristow
Just downloaded the latest update on my iPhone XR. Does seem a lot more snappy
and I'm loving the recent UI/UX changes too, especially the sending photos &
GIF changes.

Good work Facebook!

------
gigatexal
SQLite does it again! I love that they're using it for internal state
management of the UI

------
stuaxo
It's hard to be excited about anything FB do, when we know how poisonous it
is.

------
ska
Not sure how much impact this will have, most of the people I know and have
discussed this with fall into two camps: people who use FB a lot an will put
up with a bad mobile client, and people who don't want FB on their phone,
ever.

I have to go years back to think of someone who told me they just couldn't
take the bad UX of the clients so they deleted it.

~~~
monocasa
It's probably not meant for us, but instead the third world phones where
they've gotten to the point that it might not even install on a large part of
their user base.

Like I've heard from peace corps folk about how a large part of the third
world thinks of messenger as "the internet", which is absolutely terrifying.

~~~
solarkraft
As someone with a modern smartphone I'm a huge fan of these lite apps.

Spotify lite, for example, has all the features, a better (!) UI (with
material ripples) and everything loads about twice as fast.

Every app should be a lite app. Devs, please start giving a shit about
performance.

~~~
novok
I've tried FB lite, and found it to be slower than the real app. FB lite seems
to act like a fancy web browser, so each interaction needs to download it's UI
along with content.

------
Doctor_Fegg
Here's a way in which they can save 100% of the size: Stop stubbornly barring
mobile clients from using the web interface. This is why I don't use Facebook
Messenger at all.

~~~
monocasa
But then they don't have permissions to slurp up all of your contacts, watch
all of your SMS, and listen to your microphone...

~~~
Scapeghost
I really wish iOS would allow you to select which contacts/photo album to give
an app access to, instead of all hundreds/thousands of them.

~~~
amarshall
For photos, I wish iOS would not require a permission at all in the case where
I just want it to open an OS-controlled file picker and then give the app the
one photo, akin to copy-pasting it. No reason to give access to every photo
when only N are picked.

~~~
kitsunesoba
It’s been a while since I worked with the photo library APIs in iOS, but as I
recall there in fact _is_ an API that apps can use to request the user to pick
individual photos from an OS picker without further permissions. Most apps
just don’t use it because they all want to do their own custom photo picker
UIs (even privacy focused apps fall victim to this).

------
BooneJS
Sounds neat, but I’ll continue to use “request desktop website” on mobile
safari in a vain attempt to prevent running whatever else this app does
besides chat.

------
jandrese
This seems like an incredibly low bar to hurdle. FB Messenger on iOS is
legendarily bloated. In the couple of weeks I had it installed it also managed
to be the biggest battery drain on my phone, even more than some 3D games.

~~~
beatgammit
Is this incompetence or aggressive data mining? I fail to see how a texting
client is that complicated...

~~~
jandrese
Have you seen how much memory and CPU time Signal uses on the Desktop? Or
Slack? The era of running a chat app for almost no resources is gone unless
you're an IRC holdout.

~~~
pier25
> Have you seen how much memory and CPU time Signal uses on the Desktop? Or
> Slack?

Aren't those using Electron?

~~~
saagarjha
I think that's the point.

~~~
pier25
Right, but if Messenger is not using Electron why is this related?

~~~
MikusR
All of those are chat apps.

~~~
solarkraft
And bloated. And using web technology. Wonder whether those are related.

------
throw03172019
Does having 40 contact screen designs seem normal?

------
cjamesd
This is a bit cynical (and borderline paranoid) but what if the reason for the
rewrite was to remove privacy-violating code that was becoming a greater and
greater liability? Also, wonder if they needed to do this to make way for end-
to-end encryption we've been hearing about?

------
djsumdog
I wonder if this will break libpurple-facebook or the Matrix-facebook-bridge

------
listsfrin
Too little and too late. I feel like they lost a whole generation of people.

~~~
thehappypm
I tried to use FB Messenger for a group thread for a ski trip, and I got a
resounding "ok boomer".

~~~
Jaruzel
off topic, but I absolutely hate the millennial put-down of 'ok boomer'. They
use it for anyone who is older than them, regardless. I'm Gen-Z and being
called a 'boomer' is offensive.

------
solarkraft
To me a lot of the new architecture just seems obvious (don't keep the same
view 40 times, don't invent your custom app specific everything ...) and I
really wonder how the original project could derail that far. Too many
resources? Institutional bloat?

That said I find it a bit heart warming that all the major apps are now
between 1/2 and 1/4 the size of what they were just a few years ago. I didn't
expect the tech companies to ever realize the problem with insane sizes. Is a
similar debloating happening to Electron apps?

------
tim--
I wonder what this means for older versions of Messenger? Facebook talks about
rewriting their server logic to support all the removed code from the mobile
interface, but does this mean that we will soon see support for < iOS 10
(which Messenger does not support for new versions, as far as I ma aware) be
dropped?

It's pretty sad that a Messaging app can't be run on a perfectly fine nine
year old device. Bring back IRC :)

------
1023bytes
So it's basically MVVM with SQLite as the model?

------
adam_fallon_
I feel like I had an aneurysm reading this. For 6 paragraphs the repeat that
they shrunk the lines of code down, that the rewrote the whole thing and that
it’s a massive undertaking and that a message app should be small. 6
paragraphs of that slightly reworded and I just gave up. I honestly think this
was written by a bot.

~~~
adam_fallon_
Also just LOOK at this empty state.

12 buttons. And that’s apparently stripped down. Yikes.

[https://imgur.com/gallery/drOgDwF](https://imgur.com/gallery/drOgDwF)

~~~
alpacaillama
That’s not the new version. You haven’t received the update yet.

------
ckdarby
It'll suck for the SEO team at LightSpeed point of sale company.

FB named a open source project the same name as a company.

~~~
pbhjpbhj
I don't know if it's clear it will suck? You just advertised their company,
it's the first time I ever heard of them. It's not like LightSpeed is an
unheard of name? It's a stock trader, web filter, data warehousing company,
and probably a million other things. Novel names are hard to come by.

------
jpeeler
Wish they had gone into more details about the budgets. Unless a project is
bug fix only for life, how can one set a binary size or lines of code upper
limit? I've heard that the best developers delete more than they write, but in
practice I don't think that happens very often.

------
thekid314
Security isn't mentioned once.

I really wonder if in their meetings they sold the speed and lighter weight as
a bonus for the user or for the collection of data on the user. This must
reduce their overhead and be kinder on their servers.

------
Thorentis
I still aren't 100% sure what they're using Sqlite for? Are they storing
templates as blobs? Are the storing template logic in the table? How did that
make things faster? Anybody who has more detail care to explain?

~~~
NoodleIncident
It sounds like the entire client-side state of their app is in SQLite

------
beefield
Assuming one hates notifications, is there _any_ reason why anyone would want
to use app over m(basic[1]).facebook.com?

[1] to access messenger because fb stubbornly thinks I want to install their
crap/spyware on my phone

~~~
ajconway
Nice UI and OS integration — that's precisely why native apps exist.

------
llovan
RIP React Native

~~~
zerubeus
Messenger was never in React Native
[https://reactnative.dev/showcase](https://reactnative.dev/showcase)

------
chendragon
Now if only they would rewrite the web application too, or release that
desktop app they were talking about last year. The web app is much, much
slower than the phone app.

------
manigandham
Facebook's video player experience is absolutely terrible.

------
z3t4
Once you are several years into a software project, everything feels like a
weekend project, you somehow lost all sense of time-cost/benefit...

------
jbverschoor
Thank you! Eventhough I've removed Messenger from my habits, I checked it out,
and it's really snappy and super fast with starting up.

------
moron4hire
Do they still block use of the web UI for Messenger in mobile browsers, unless
I check "show Desktop version" in my browser settings?

------
dlsso
They said they reduced code 84% but the numbers they gave are a 79% reduction.
If they're using different metrics they should explain.

------
anant90
> And yet, for the people using the app, it won’t look or feel much different.

Yikes. Okay, I know I'm maybe being a bit unfair here, but I'm sorry to say
that this is one of the weakest engineering blog posts I've ever read. This
seems to be a massive "let's end the craziness and finally pay our tech debt"
effort. Good for them, but not something that excites me about working at
Facebook.

~~~
Smaug123
Really? I, for one, think it's very important to work somewhere that pays its
tech debt on time.

------
_bxg1
Was the previous one React Native? Seeing the talk about UI abstraction layers
and given that this is Facebook

------
eyegor
I'm truly shocked how many resources are dedicated to maintaining a chat app
that essentially just talks to an api. Seems like you could easily build and
maintain a simple chat system with <5 developers. You wouldn't have shiny new
features, but it would by coincidence be faster and simpler. Networked chat is
a standard project in university.

~~~
imron
> Seems like you could easily build and maintain a simple chat system with <5
> developers

Yes you could. Note however 'simple chat system'.

To build a global messaging app used by hundreds of millions of people is a
whole different ball game.

By comparison, before acquisition by Facebook, Whatsapp had a team of ~50
people, and that was considered lean. Based on that, it would seem you're
about an order of magnitude off.

~~~
thu2111
True but, be aware that those 50 people did everything including the servers,
the operations, the BI, oh and also maintained clients for like 8 different
mobile platforms including ultra constrained ones like j2me and blackberry. If
you look just at the iOS client, 5 people at WhatsApp on it would probably be
a bit too high.

The issue here is only partly inherent complexity of the feature set. The real
problem Facebook had is one I don't see discussed in either the blog post or
this thread, which was organizational. The way they structured their mobile
apps was as a huge shared codebase with many disparate teams just checking
code into it whenever they wanted. To the extent there was any architectural
planning at all it came from some small shared library teams who were in no
position, managerially, to enforce their will on the others. The blog post
makes clear that a huge portion of their problem was multiple teams inventing
their own ways of doing things and creating stuff that want necessary, along
with a lot of pointless duplication because there was so little coordination
and thus so little code reuse.

The new app doesn't sound like anything special design wise, and that's the
point: for the first time they've done things more conventionally. They now
have someone who can dictate to every feature team "thou shalt use sqlite with
these schemas" and other rules.

------
chj
>from more than 1.7M lines to 360,000.

At first look, I thought it is 36k, that would be truly great.

------
tiffanyh
Does anyone know if FB dropped Messengers C code for WhatsApp Erlang based
code?

------
_bxg1
I'd be curious to see more details on how pub/sub works with SQLLite

------
cbhl
It looks like polls aren't yet implemented in the rewrite?

------
noncoml
Project lightspeed required 23.94 MB / 11.83 MB to download the webpage and
made the browser crawl on a i7 32Gb PC. Oh the irony..

------
trustfundbaby
So ... no more React? what did they use? swift?

------
SkyMarshal
The technical meat of this post is below. It looks like they mostly eliminated
functionality in their app code wherever it was redundant with either OS
functionality, SQL Lite capabilities, or the Messenger backend servers at
Facebook's datacenters.

 _> One of our main goals was to minimize code complexity and eliminate
redundancies. ... To build this unified architecture, we established four
principles: Use the OS, reuse the UI, leverage the SQLite database, and push
to the server._

 _> 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._

 _>... the existing OS often does much of what’s needed. Actions like
rendering, transcoding, threading, and logging [and JSON processing] can all
be handled by the OS._

 _> To simplify and remove redundancies, we constrained the design to force
the reuse of the same [UI] structure for different [UI] views. So we needed
only a few categories of basic [UI] views, and those could be driven by
different SQLite tables._

 _> Now, ... All the caching, filtering, transactions, and queries are all
done in SQLite. The UI merely reflects the tables in the database._

 _> We developed a single integrated schema for all features. We extended
SQLite with the capability of stored procedures, allowing Messenger feature
developers to write portable, database-oriented business logic, and finally,
we built a platform (MSYS) to orchestrate all access to the database,
including queued changes, deferred or retriable tasks, and for data sync
support._

 _> MSYS is a cross-platform library built in C that operates all the
primitives we need. ... With MSYS, we have a global view. We’re able to
prioritize workloads. Say the task to load your message list should be a
higher priority than the task to update whether somebody read a message in a
thread from a few days ago; we can move the priority task up in the queue._

 _> With MSYS, it’s easier to track performance, spot regressions, and fix
bugs across all these features at once. In addition, we made this important
part of the system exceptionally robust by investing in automated tests,
resulting in a (very rare in the industry) 100 percent line code coverage of
MSYS logic._

 _> For anything that doesn’t fit into one of the categories above, we push it
to the server instead. We had to build new server infrastructure to support
the presence of MSYS’s single integrated data and sync layer on the client._

 _> Coordinating logic between client and server is very complex and can be
error-prone — even more so as the number of features grows. ... _

_> Similar to MSYS on the client, we built a server broker to support all
these scenarios while the actual server back-end infrastructure supports the
features._

 _> [To minimize code-base growth] We also built a system that allows us to
understand how much binary weight each feature is bringing in. We hold
engineers accountable for hitting their budgets as part of feature acceptance
criteria. Completing features on time is important, but hitting quality
targets (including but not limited to binary size budgets) is even more
important._

------
chadlavi
tracking you everywhere you go is easier than ever!

------
buboard
how does one manage to make a _chat_ app bloated in 2020?

~~~
ycombonator
Abstraction craze. React Native etc etc.

------
Priem19
A great way to speed up the pace to their next scandal.
[https://www.quitfacebook.org](https://www.quitfacebook.org)

------
miki123211
Am I the only one who thinks 86mb for an app is about 86 times too much?

Windows Messenger was about 900k. Sure, it only did text, but Skype wasn't
that big either. I'd accept 20mb for stickers, givs and stuff but 80? And 300k
lines of code? For a messaging app? It just seems... unreasonable to me.

~~~
paxys
Most of that is likely retina-friendly images/icons.

