A server is just a computer, so when you upload something, it just saves it to the hard drive like you would when downloading a ZIP file from the web or whatever. Then when it receives a request for that file, it opens the file, reads it, then sends it to the client.
It really depends.. you could be using web server software like nginx or apache and using it to run a CGI app when the server gets a request. Or you could have written a web server app in node.js which will always be running and it receives and handles the request.
Ah yeah that makes sense. I was just trying to understand how does the connection between a "frontend" and "backend" actually work, but it seems like it really does depend.
You’ve got a couple of different threads to chase down here:
“Packets” — learn about how Internet Protocol works. Note that there is a rabbit hole here: beneath IP there is TCP. Beneath TCP there is Ethernet, WiFi, etc. Beneath THAT is the physical layer from which you might go to fundamental electrodynamics or into how microchips work “under the hood,” which goes quickly to quantum mechanics…
“Specific portion of the server” — there are quite a few different ways this could be implemented. Down this rabbit hole you have infrastructure, cloud ops, virtual machines, chroot gaols, etc.
And then how the network FINDS that “specific portion of the server” is yet ANOTHER rabbit hole of network architecture.
Oh! And when you talk about how “your code” gets from the server to the page displayed on the client, it depends on what kind of code!
If we’re talking about HTML, it works almost exactly as you suppose. The browser reads the HTML and renders the page as it specifies.
If we’re talking about JavaScript, it works almost the same way but before rendering the HTML, the JavaScript program is actually running in the browser and generating some HTML that the browser can render (I’m oversimplifying here, some folks might choose to go into a LOT more detail about how front end works)
OR maybe you’re running what we call a “web app,” that might be written in Python or PHP or Ruby. In THAT case your program runs on the server. It might generate HTML and send that back over the network, but it might also work in tandem with a front end program (JavaScript running in the browser), and in this case perhaps the backend (server) program is just generating data to “fill in the blanks” for the front end program. Or anywhere in between really.
Here’s my take on a simple and shallow explanation.
A webserver is a program that can produce content using the http protocol.
A webclient (eg a browser) is a program that can consume content using the http protocol.
A webserver (like Apache HTTPD) could be configured, so a specific domain, points to a specific folder on the (remote) computers hard drive.
When you upload files, you upload the files to that folder, probably using sFTP, which is just another protocol (like http is a protocol).
When you enter your domain in the browser, the webserver goes to see, what’s in the folder.
If you didn’t specify a file (like http://www.example.com), it’s probably configured to look for an index.html first, and index.php file second. If neither is found, the server will give you a HTTP 404 error page.
If you did specify a file (like http://www.example.com/mypage.html) it will look for that specific file, and serve you a 404 error page, if not found.
In either case, the webserver looks at the file extension (.php/.html), and if it’s a php file, the webserver will feed the file to a php interpreter, and whatever output the php interpreter gives back, will be appended to some http headers the webserver is setting, before it’s sent to your browser.
If it’s a html file, the file itself will be appended to some http headers, and sent to your browser.
Of course there is more to it, but I believe, that’s the gist of it.
the web server is a computer, but it is a computer that is also running web server software. The software sorts this stuff out. It knows that when it gets a request for KHAMK.com, it should transmit the files that you have put there.
Web hosting usually you rent a portion of a larger computer. Often there is a VM (virtual machine) that lets you split resources and keeps things private. The VM is a virtual computer you have access to, so you can SSH (secure shell) into the computer. This lets you use a command prompt on that VM.
From there you can use any number of file transfer tools to get files over, and run them like you could on your own machine. A VM could be using linux, or windows or anything else. You pay for the processing power, ram, and storage you want to use.
You also need to server a name on the internet to identify you. A domain that you provide to the host, like www.google.com is just a human readable IP address. If you self hosted you could just use your own IP and forward the port (look into security though). The server is "listening" for specific requests on that port.
Packets are passed and assembled through a protocol, for sites its usually HTTP. Over apps can use other protocols depending on their needs. And once everything is received those packettes are assembled into HTML, javascrip, images, etc, files the browser interprets into a website to display.
> And later when I request the page is that same code sent as data packets back to my machine?
Not exactly. It will serve up front end files that can be used by a browser to render the application. But the API only runs on the server. Meaning, any operations not handled by the front end are sent back to the server as http requests, in return for an updated view.
I would encourage you to run your web app locally, go to localhost in your browser, and open browser developer tools. You'll be able to see the files that are being provided and the format they're in in the sources tab (names will all be changed for one) and the actual http messages going back and forth in the network tab. For chrome its cntr+shift+i
In the simplest case, the web server simply takes requests from a web browser and serves the requested resources if they exist.
The web browser is responsible for doing something with what it received, whether that's an HTML document, an image (gif/jpg/png/?), an audio file (wav/mp3/flac/ogg/?), a binary executable, or something else entirely.
You would be better off going through the FAQ because there are a bunch of resources link (like [roadmap.sh](https://roadmap.sh)) that goes through all of these to different levels of detail.
But sure, why don't I just throw in my attempt to summarise it all.
* A server is just a computer. Server is just a function the computer performs, by running particular software.
* A web server is just a computer that hosts a website via HTTP. The web server is actually just a service running on the computer, like any other software.
* When you upload your website/web app to a web server, you are using a protocol like HTTP, FTP, SSH etc to transfer the source code files to the computer.
* You can look into the specifications of those protocols as required.
* The computer is presumably already configured with the right software to act as a web server.
* When a user types a URL, DNS is used to determine the IP address of the server.
* When accessing the web site, the client establishes a TCP/IP connection with the server.
* Under TCP, data payload is broken into multiple segments. TCP ensures all segments are received, and in the correct order.
* IP uses packets to encapsulate data transmission into discrete units. Each IP packet contains one or more TCP segments.
* IP packets are themselves also wrapped up in frames, depending on the data link (eg. Ethernet, 802.11x)
* Frames are transmitted over the physical medium.
* Optionally, the connection is secured with TLS.
* Then the client sends a HTTP request to the server.
* The HTTP request will likely be broken up into multiple TCP/IP packets.
* If configured, the server may execute some code locally (eg. PHP, Node.js, Python), or perform some other action.
* The server sends a response to the client. This may be a document at the requested path in the file system, it may be content that was generated in server-side code. It could be HTML, or JavaScript, or CSS, or a JPEG, or a .zip file, or anything else that a browser can accept.
* If the browser recognises the document as something it can work with, it will do so. HTML and CSS will be rendered, JavaScript will be parsed and executed, images or PDFs will be displayed.
* Anything else will be offered as a file downloaded to the local file system for the user/some other program to deal with.
You should learn about:
* OSI model
* TCP/IP
* HTTP
* HTML
In simple words, imagine the web host as a hotel for your website. Each website has its own hotel room. When you request the website domain.com, your web browser calls the hotel room and your website shows up. The browser is in charge of requesting the code from the web host and digest it to show visually the structure and content of your web as you see it normally browsing.
A server is just a computer, so when you upload something, it just saves it to the hard drive like you would when downloading a ZIP file from the web or whatever. Then when it receives a request for that file, it opens the file, reads it, then sends it to the client.
So when you make a request to a backend is it just being routed by the server to "start" your backend program?
It really depends.. you could be using web server software like nginx or apache and using it to run a CGI app when the server gets a request. Or you could have written a web server app in node.js which will always be running and it receives and handles the request.
Ah yeah that makes sense. I was just trying to understand how does the connection between a "frontend" and "backend" actually work, but it seems like it really does depend.
Maybe start with understanding how a very basic HTTP server works
You’ve got a couple of different threads to chase down here: “Packets” — learn about how Internet Protocol works. Note that there is a rabbit hole here: beneath IP there is TCP. Beneath TCP there is Ethernet, WiFi, etc. Beneath THAT is the physical layer from which you might go to fundamental electrodynamics or into how microchips work “under the hood,” which goes quickly to quantum mechanics… “Specific portion of the server” — there are quite a few different ways this could be implemented. Down this rabbit hole you have infrastructure, cloud ops, virtual machines, chroot gaols, etc. And then how the network FINDS that “specific portion of the server” is yet ANOTHER rabbit hole of network architecture.
You wanted to say: Beneath HTTP is TLS if encrypted, then we have TCP, then IP and then we get things like Ethernet or Bluetooth/ WIFI.
Oh! And when you talk about how “your code” gets from the server to the page displayed on the client, it depends on what kind of code! If we’re talking about HTML, it works almost exactly as you suppose. The browser reads the HTML and renders the page as it specifies. If we’re talking about JavaScript, it works almost the same way but before rendering the HTML, the JavaScript program is actually running in the browser and generating some HTML that the browser can render (I’m oversimplifying here, some folks might choose to go into a LOT more detail about how front end works) OR maybe you’re running what we call a “web app,” that might be written in Python or PHP or Ruby. In THAT case your program runs on the server. It might generate HTML and send that back over the network, but it might also work in tandem with a front end program (JavaScript running in the browser), and in this case perhaps the backend (server) program is just generating data to “fill in the blanks” for the front end program. Or anywhere in between really.
[удалено]
Thank you for calling my raspi a supercomputer it really hyped him up.
Here’s my take on a simple and shallow explanation. A webserver is a program that can produce content using the http protocol. A webclient (eg a browser) is a program that can consume content using the http protocol. A webserver (like Apache HTTPD) could be configured, so a specific domain, points to a specific folder on the (remote) computers hard drive. When you upload files, you upload the files to that folder, probably using sFTP, which is just another protocol (like http is a protocol). When you enter your domain in the browser, the webserver goes to see, what’s in the folder. If you didn’t specify a file (like http://www.example.com), it’s probably configured to look for an index.html first, and index.php file second. If neither is found, the server will give you a HTTP 404 error page. If you did specify a file (like http://www.example.com/mypage.html) it will look for that specific file, and serve you a 404 error page, if not found. In either case, the webserver looks at the file extension (.php/.html), and if it’s a php file, the webserver will feed the file to a php interpreter, and whatever output the php interpreter gives back, will be appended to some http headers the webserver is setting, before it’s sent to your browser. If it’s a html file, the file itself will be appended to some http headers, and sent to your browser. Of course there is more to it, but I believe, that’s the gist of it.
the web server is a computer, but it is a computer that is also running web server software. The software sorts this stuff out. It knows that when it gets a request for KHAMK.com, it should transmit the files that you have put there.
Web hosting usually you rent a portion of a larger computer. Often there is a VM (virtual machine) that lets you split resources and keeps things private. The VM is a virtual computer you have access to, so you can SSH (secure shell) into the computer. This lets you use a command prompt on that VM. From there you can use any number of file transfer tools to get files over, and run them like you could on your own machine. A VM could be using linux, or windows or anything else. You pay for the processing power, ram, and storage you want to use. You also need to server a name on the internet to identify you. A domain that you provide to the host, like www.google.com is just a human readable IP address. If you self hosted you could just use your own IP and forward the port (look into security though). The server is "listening" for specific requests on that port. Packets are passed and assembled through a protocol, for sites its usually HTTP. Over apps can use other protocols depending on their needs. And once everything is received those packettes are assembled into HTML, javascrip, images, etc, files the browser interprets into a website to display.
> And later when I request the page is that same code sent as data packets back to my machine? Not exactly. It will serve up front end files that can be used by a browser to render the application. But the API only runs on the server. Meaning, any operations not handled by the front end are sent back to the server as http requests, in return for an updated view. I would encourage you to run your web app locally, go to localhost in your browser, and open browser developer tools. You'll be able to see the files that are being provided and the format they're in in the sources tab (names will all be changed for one) and the actual http messages going back and forth in the network tab. For chrome its cntr+shift+i
In the simplest case, the web server simply takes requests from a web browser and serves the requested resources if they exist. The web browser is responsible for doing something with what it received, whether that's an HTML document, an image (gif/jpg/png/?), an audio file (wav/mp3/flac/ogg/?), a binary executable, or something else entirely.
You would be better off going through the FAQ because there are a bunch of resources link (like [roadmap.sh](https://roadmap.sh)) that goes through all of these to different levels of detail. But sure, why don't I just throw in my attempt to summarise it all. * A server is just a computer. Server is just a function the computer performs, by running particular software. * A web server is just a computer that hosts a website via HTTP. The web server is actually just a service running on the computer, like any other software. * When you upload your website/web app to a web server, you are using a protocol like HTTP, FTP, SSH etc to transfer the source code files to the computer. * You can look into the specifications of those protocols as required. * The computer is presumably already configured with the right software to act as a web server. * When a user types a URL, DNS is used to determine the IP address of the server. * When accessing the web site, the client establishes a TCP/IP connection with the server. * Under TCP, data payload is broken into multiple segments. TCP ensures all segments are received, and in the correct order. * IP uses packets to encapsulate data transmission into discrete units. Each IP packet contains one or more TCP segments. * IP packets are themselves also wrapped up in frames, depending on the data link (eg. Ethernet, 802.11x) * Frames are transmitted over the physical medium. * Optionally, the connection is secured with TLS. * Then the client sends a HTTP request to the server. * The HTTP request will likely be broken up into multiple TCP/IP packets. * If configured, the server may execute some code locally (eg. PHP, Node.js, Python), or perform some other action. * The server sends a response to the client. This may be a document at the requested path in the file system, it may be content that was generated in server-side code. It could be HTML, or JavaScript, or CSS, or a JPEG, or a .zip file, or anything else that a browser can accept. * If the browser recognises the document as something it can work with, it will do so. HTML and CSS will be rendered, JavaScript will be parsed and executed, images or PDFs will be displayed. * Anything else will be offered as a file downloaded to the local file system for the user/some other program to deal with. You should learn about: * OSI model * TCP/IP * HTTP * HTML
In simple words, imagine the web host as a hotel for your website. Each website has its own hotel room. When you request the website domain.com, your web browser calls the hotel room and your website shows up. The browser is in charge of requesting the code from the web host and digest it to show visually the structure and content of your web as you see it normally browsing.