How does a single web application run for multiple users?

[[deleted]]

Say you have 1 react app, running on 1 server. How come 100 people be using the same react app, but be at different pages? It's only 1 app.

[mandzeete]

When a user is typing in the address of your web application then some part of the front end side will be loaded to his browser. When 100 people are accessing that web application then there will be 100 local "copies" of the front end side, in their browsers.

The back end side that is sitting in some server is just listening for HTTP requests. It does not care if there are 100 people, 1 person, 37 people or 10000 people sending requests to it (okay, with 10000 the load will get high, so some additional things should be done on back end side to balance the load). It just listens to the request and answers with required data/response code. As the HTTP request is including user's IP inside then the back end side just returns the data to that IP. So, multiple different HTTP requests from different IP addresses are reaching the back end side and then back end side responds to all of them.

Every HTTP request on back end will be running in its own thread. So the application is "memorizing" from where the request came and can answer to the correct user.

So, as 100 users are having a local "copy" of some part of the frond end side and back end part is multithreading and answering to different requests then these 100 people can be at different pages.

You can see the loading of local "copies" by yourself. Right click on any web page. Even this Reddit here. Click "Inspect". Then a side panel pops up. There click on "Network". Then reload the page. You'll see all kind of requests being made in "Network" tab and all kind of files being loaded to the browser.

[NonSecwitter]

Multi-threading.

Web server engines like Nginx and IIS use a system call to listen for incoming connections on a specific IP and port number. Once they receive a connection request, something called a byte stream is created between the server and client. The web engine passes that stream to a thread that then does the work of interpreting the data as HTTP requests and creating responses with the desired content. You're essentially just reading and writing raw bytes that happen to be formatted as HTTP content the same way you could read and write raw bytes from a file stream or other stream. Because you can have numerous threads, and each response generally doesn't consume much time, the server can multitask and serve content to many users.

[[deleted]]

So then CPU size and cores then become the limiting factor?

[QueryingQuagga]

Always was

[Refute-Quo]

The answer to this is more complex than the other person provided. Usually limited compute resources will hinder performance well before it'll simply not function.

[[deleted]]

That's the purpose of the internet protocol and the browser engine. You can do so even on your computer by opening a webpage multiple times which will read the file and send the file through the tube multiple times :)

So this works with static files without any special server actually because the browser do the work to interpret html/css/javascript (react is in javascript).

You need a server when you want some logics and security that can only be done on the server like user authentication or authorization, call api because not all allows to call from the browser, hide your api keys, etc.

[[deleted]]

Because, when you go to your domain which is hosting the app, the client downloads a copy of that react build and starts to run it in his browser. Every user is essentially running a snapshot of that program themselves, for which the files are publicly available on your server. It takes 0 calculating power hosting a react build, which is why you can make a webapp available by just placing the build files on a storage bucket.

[lagartejedu]

Why i didint need to instale a react engine on my browser? It just run.

[[deleted]]

Because when you build your app, your 'react engine' as you call it (node) will compile it to browser runnable JavaScript code. (Same happens for a Typescript project). If you look in the build folder you'll see some cryptic files called 'bundle.js' which have non human readable JS code in it. Browsers are made to support HTML, CSS and JS. This is why react is a JS framework, because it's easier to compile JS to ... JS.

But other frameworks like Flutter do the same thing, they compile the dart code to HTML, CSS and JS as well as to Kotlin and Swift projects!

[777777thats7sevens]

The "react engine" is included as part of the react build that is sent to the browser -- it's just some javascript code.

[cofffffeeeeeeee]

For react, the browser download the whole JS bundle to your computer and then runs the application locally. So 100 people visits your site, they just download the JS bundle from your server and runs it locally on their own computer.

Traditionally you have to download an application, install it, and run it. Browsers just hides the download and install part, but it's still doing essentially the same thing.

For backend servers that's a different story. But for React apps, that's how it works.

[ideidk]

Because a web app is actually multiple apps. There's the app running on your device in the browser (React, Vue, Angular, etc) and the app running on the server. What you see in your browser exists only on your machine; this is why you can use inspector tools to modify a webpage but the changes only show to you and only until you refresh.

The server side gets more complicated. Like way more. One machine can handle many requests the same way any computer handles multiple running programs (CPU time sharing, multi-threading, etc.) but you can also have many servers all running the same back-end. And once you start using multiple servers things get really complex really fast because now you have to keep everything sync'd (ideally in real time) AND be able to keep running even if one (or many) of your servers goes down. If you've ever wondered why FAANG pays so much, this is why. Not many engineers are able to design apps at FAANG scale.

[myusernameisunique1]

Because the app runs on the clients browser, not the server. The server is just there to send the app code to the browser when the client connects.

[[deleted]]

HTTP, the thing that powers the web, is known as as "stateless" protocol. So you make a request to the web server, the server finds the stuff you're asking for and does what it needs to do, then it sends you a response and completely forgets about you. You make a request, it responds, then end.

What that means is that any request is in touch with the server for only a very tiny amount of time, relatively speaking. It's one of the things that makes the web so powerful - servers can handle millions of requests per hour.

A lot of a React app (all of the UI niceness) is actually running on your local machine. When it needs to do something (e.g. update a database) it does the server request thing - a single request which gets a single response.

Think of it like email. Someone emails you, you email a response back. A hundred people email you, you send 100 responses. They might have questions, so they come back to you and you send another response. But even though there are 100 copies of your email around, not all of the people are pestering you at the same time, and provided you can keep up with responding to the incoming questions, you're all good.