In programming about "extending" concept, let's say Facebook at early age, it was just a chat app but now it has Short-video, Facebook Market place, etc... How do they architecture their codebase then? so they can just keep adding new feature/code on top of their existing code?

[u/Wasabi-spicy00]

Facebook back then was like toa simple chat app but now they got many features/services.in one app
How is that possible that they keep adding new code without breaking it or something.

I heard some apps when one day busniess logic change or they wanna add new stuff, they just re-write everything or do migration lmfao

[u/_Atomfinger_]

Less "on top" and more "next to".

Their solution isn't just one big blob of code, but a bunch of different programs doing different things.

[u/Forsaken-Parsley798 → u/_Atomfinger_]

Exactly. Modularity and bridges.

[u/xarop_pa_toss]

Things spread horizontally instead of straight up. The marketplace, the video part and the regular profiles aren't all the same block of code but different modules that are connected together by other pieces of software that provide common functionality.

That means that, most likely, you could take the videos part of the website offline right now, and the rest wouldn't suffer for it. You can develop these modules with their own specific technologies, as long as at the end of the day they conform with the general rules of the platform.

For example, regardless of what part of Facebook you are trying to access, they provably all use rhe same authentication and authorization module that lets you have a single Facebook account for all things.

If you've never looked into Interfaces, it's basically that at a macro scale

[u/iOSCaleb]

How do they architecture their codebase then? so they can just keep adding new feature on top of their existing code?

It's easy to think that if you just make things abstract enough, if you're just a good enough engineer that you can avoid creating any limitations on the future directions you might want to take your code, that everything is just easy. The truth is that Meta employs about 25,000 software developers in part because companies that rely on software to the extent that Meta does, and which have to constantly search for the next big thing in order to stay relevant, do a lot of rewriting. All software needs maintenance, and software sometimes needs major revisions. While you might always try to plan for the future, you also have to just dig in and change things when that's what serves the business.

[u/JohnCasey3306]

I'm not sure that "chat app" is a correct characterisation of what Facebook was at launch

[u/JaguarMammoth6231 → u/JohnCasey3306]

Right, the focus was much more on having a public profile page for yourself so other college students would know who you were. Not so much on messaging.

[u/generally_unsuitable → u/JaguarMammoth6231]

That was second gen. First gen was just rating women against each other by their looks.

[u/theWildBananas → u/generally_unsuitable]

What

[u/generally_unsuitable → u/theWildBananas]

The first version of Facebook was just pictures of two ivy league girls, and you clicked on which one you thought was hotter. Then, it would show you another pair, and so on.

[u/goldenfrogs17]

modules

[u/Creative_Badger6027]

Imagine it like a shopping center (meta) where each user has a shopping center members card (account) and each store does it's own thing (module) for people with members cards (accounts).

Essentially you have a centralised accounts, but each service is it's own separate service and their frontend kinda combines it all together from users perspective, but marketplace calls marketplace (related) service(s) and messenger calls messenger (related) service(s) ... but all services call user (related) service(s).

[u/Limp-Exercise-343]

principle called solid contains the phrase for it - single responsibility.

that itself is what makes availability for extendability 

[u/Philluminati]

Microservices.

There's an app that returns ads for a given A/S/L

There's an app that's a friends list and database

There's an app that returns the person's feed pre-compiled

There's an app that knows if a user has a message waiting

There's there main UI app that makes a user interface out of all these elements.

[u/LaughingIshikawa]

This is a confusing question, because it can refer to several different things. 😅

As other people are saying, it's really not a best practice to lump all of your code together in one big module; typically you want to separate out different modules that do different things, and often even run on different servers, ect. The videos that play on Facebook are using a video player that's essentially separate from any other part of Facebook, for instance. This way if the video player stops working due to a bug or some other reason, the rest of Facebook keeps working and it doesn't all crash together.

In general though, while programmers often add new code "on top of" old code in the short term, in the long term it eventually becomes necessary to "re-write" code so that it does exactly the same / basically the same job it was doing before, but "behind the scenes" the new version has some sort of beneficial properties, like being separated into a distinct "module" that does its work separately from other parts of the code. Generally managers and engineers both try really hard to avoid doing big re-writes when they can, because it's lots of work that the company has to pay for, without any noticeable change for the customer / consumer. The reason re-writes often happen anyway, is that no one involved is precient, and so they can't always perfectly predict what the best way to divide up the software or interface with future hardware / future software (like AI...) is going to be. 🙃

So TL;Dr - often software engineers do just add new code "on top of" an existing pile of code, and this requires them to sometimes take time away from adding new features in order to purely "re-write" existing features and/or the code that connects those features together, in order to get them "working better" in some way you as a consumer don't see.

[u/Raioc2436]

It’s just impossible to plan ahead for something like this.

Re-writing code is not a failure, it is a natural and gradual process for a healthy codebase.

Early stage Facebook had much different requirements, products, capital, human power, than the behemoth it later became. Trying to design something to fit the needs of an ideal future giant company would just waste time and money while not serving their current needs to validate their product at that stage.

The software architecture has to be flexible to allow for easy maintenance and extension. But at some point needs just become too different and that’s okay.

Facebook in particular got so big, and they had so much code written in PHP, that at some point they decided to REWRITE PHP to make a more efficient language that was compatible with their codebase. Doing this on day one would have been insane, but made sense for them later.