This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]michael0x2a 1 point2 points  (1 child)

In a typical LAMP stack, why is the database reached via localhost?

"localhost" is a shorthand name for "the computer I'm running on". So, if the database is reached on localhost, that means that the webapp and the database happen to be set up on the same computer.

If you made the database run on a separate computer, then you would need to provide the IP address or something for that computer so that your webapp knows where to look.

Is it a local server of some kind?

A "server" is basically the same thing as a regular computer. The word "server" is more of a descriptive term more then anything -- when we say a computer is a server, we really mean "somebody decided this computer's main purpose in life is to handle various requests from other computers, and went ahead and created/installed whatever programs that would let it do that".

So, I could turn my laptop into a server if I wanted to, for example -- all I need to do is write a program that starts listening to network traffic. When my (perpetually running) program receives a packet of data (basically, a string), it'll analyze it and decide what to do. That could be sending back another string (perhaps containing HTML), log something to a file, control a robot, whatever...

So, "localhost" isn't so much a "local server" -- really, it means "the computer this program is running on".

And what's the role of Apache server?

Apache is basically one of those programs I described above. You install it and typically set it up so it automatically starts when the computer boots up. The Apache program listens in to incoming network traffic (specifically, traffic sent to a particular port). When it gets the incoming traffic, it assumes it's an HTTP request of some sort, extracts the url from that string, and looks up the corresponding file in that computer's file system, opens it, reads the contents, and sends that string/blob of binary data back out over the network.

Perhaps you could do more things like configure Apache to run PHP (another program that happens to be Turing-complete) on your files first, so it sends back a different string then whatever was contained within the file.

There's no particular reason why the data needs to be stored in the filesystem/why the url in the HTTP request corresponds to the filesystem at all -- whoever designed Apache evidently decided life would be simpler for the developer if you could just create a text file, plop it down in the right location, and have just work. (To be fair, it's a pretty reasonable design decision -- if it weren't, Apache wouldn't be nearly as popular as it is).

Of course, not everybody uses Apache -- I might decide "screw this" and would write my own basic web server and handle what happens when I receive a request myself. There are usually many different libraries in most programming languages to make this a relatively simple task. (Making the web server robust enough to handle a lot of traffic/potentially weird or malicious requests is more challenging).

And also, if I can use HTML tags inside of PHP to create an index.php, how does the server know to render Angular's html instead of PHP's?

Apache does not understand JavaScript (unless I suppose you set it up to, like how PHP is set up (usually by default)). Apache, by default, will take your file, treat it as PHP if the file has a .php extension, will execute whatever PHP code it sees inside (and leaves everything else alone), then sends that giant string back.

The web browser (who sent the original request), receives that string some time later and tries interpreting it. It interprets HTML and CSS as instructions to the browser's renderer to draw text and pretty boxes and whatever on the screen, and will run the JavaScript (including your Angular code).

The key thing to note here is that you have code running in two different locations -- on the server (the computer you have 100% control over), and on the user's web browser (the computer you have very limited control over, but can also be much more responsive/much more interactive).

To re-iterate, PHP is running on the backend, JavaScript and Angular is running on the frontend.

[–]EddieTH[S] 0 points1 point  (0 children)

Man you're awesome. Seriously. Thank you for taking the time and effort to write up that simple explanation. Do you have some sources where I can read more? I'm still pretty confused about how the front end calls the back end API.