We Keep Coding

A question about how web applications work and how server-client is implemented

This is kind of a weird question I think to ask, but I have browsing about for the past some time and cannot find a clear definite answer.
I understand that a client connects to its own server and communicates with the web-server through sockets and I kind of see how that works in php (I have never used php but have used sockets before so I understand the concept).
The issue is I'm trying to get a real view of this.
The question is, do websites generally use sockets and contact a web-server to fetch data or the actual html? Or is it a rare choice made in some areas?
If it is generally used, then is the "real" js usually in the server? or is it client-side (for performance sake)?
Context:
Let me explain a bit where I'm coming from, I'm not a web expert, but I am a computer engineering student so most concepts are easy to understand. A "real"-er view of this would be very helpful.
Now, onto why I'm asking this. I'm developing a web-app as part of a project and have done a fair bit of progress on it but everything was done on a local dev server (so basically a client?)
I've started wondering about this because I wanted to use a database for my website and since I want to connect to something, I will need to connect to a web-server first (for security sake).
My question's intent is to guide me on how and most importantly, where, to setup this server.
I don't think showing any code would be of help here, but assume I have my client running on localhost:1234, my database on localhost:3306, I think I should have a web-server on another port so I can establish this communication, but I want to do it in a clean and legitimate way so all of my current solutions can be ported online with little to no changes (except the obvious)

There's a bunch to unpack here.
First of all, servers can be distant or local. Usually they are distant, local server are mostly used for development purposes.
Even if your server is on your local machine, it still isn't the client. The client is the part that is connecting to your server. For web development it is usually the user browser.
Javascript is a language that can be used server-side, with a NodeJS server, but more often client-side, in your user browser.
Your website, or web application, communicate with your server through various means. Most common one is the HTTP protocol, used to make server requests such as data request to populate your page (in case of an API server, REST or otherwise), or simply request the actual page to display in the browser. The HTTP protocol works by resolving URLs, and making requests to your server registered to this url using special methods such as GET, POST, DELETE, etc...
Sockets are used to create a persistent connection with your server that works both ways. It is mostly used for realtime updates, such as a live chat, as it allows you to push updates from the server instead of having the client request everything.
In most cases the database can be found on the same server as the one serving the website or application, as it is a lot easier to handle, and often faster without the extra networks requests to get the data. However it can be placed on another server, with it's own API to get the data (not necessarily web related)
Ports such as 1234 or 3306 are often used for local development, however once your move your project to a host service, this is usually replace by urls. And the host service will provide you with a config to access the associated database. Or if you are building your own server you might still use ports. It is heavily dependent on your server config.
Hope this clear some things up.

In addition to #Morphyish answer, in the simplest case, a web browser (the client) requests an URL from a server. The URL contains the domain name of the server and some parameters. The server responds with HTML code. The browser interprets the code and renders the webpage.
The browser and the server communicates using HTTP protocol. HTTP is stateless and closes the connection after each request.
The server can respond with static HTML, e.g. by serving a static HTML file. Or, by serving dynamic HTML. Serving dynamic HTML requires some kind of server language (e.g. nodejs, PHP, python) that essentially concatenates strings to build the HTML code. Usually, the HTML is created by filling templates with data from the database (e.g. MySQL, Postgres).
There are countless languages, frameworks, libraries that help to achieve this.
In addition to HTML, the server can also serve javascript that is interpreted in the browser and adds dynamics to the webpage. However, there could be 2 types of javascript that should not be mixed. NodeJS runs on the server and formats the server response, client javascript runs on the browser. Remember, client and server are completely isolated and can communicate only through an HTTP connection.
That said, there ways to make persistent connections between client and server with WebSockets, and add all kinds of exotic solutions. The core principle remains the same.
It does not matter if server software (e.g apache, nginx) is running on your local machine or anywhere else. The browser makes a request to an address, the DNS and network stack figures out how to reach the server and makes it work.

Why script tags referencing "localhost:3000" fail

I am in the middle of a massive refactoring of my companies' web services and in doing so we are splitting out our static web files (HTML, CSS, JS) from our auth server and our API service. Our migration plan requires us to keep the old web server for backwards compatibility, therefore in order to do local dev I need to setup all my script tags to reference "localhost:3000", however, when I do that the requests fail in the browser
I can go directly to "localhost:3000/scripts/core.js" just fine in the browser, but if I put the exact same URL into a tag, all of a sudden the request fails in Chrome. Doesn't give me an error or anything, just says "failed"
Anyone know what I need to do to get this to work?

Because "localhost:3000/scripts/core.js" is a filepath name but "http://localhost:3000/scripts/core.js" is not. The first gives no transport mechanism but tries to attempt to open file:/// while the second specifies HTTP.
So test Or https:// as the case may be.
As far as SSL goes, this may be a separate issue. Is your SSL certificate signed for your local server or at least self-signed and accepted by your browser? Enquiring minds need to know but this may need to be a separate question.

What's the best practice for developing AJAX apps locally and deploying them on the fly?

I'm new to AJAX development. Due to same-origin policy, the most inconvenient thing for me so far is to modify the host information string (such as absolute URLs) in JavaScript files every time whenever I try to deploy the local files to the remote. I thought about writing a shell script for doing this but it seems awkward and not flexible. What's the best practice for doing this?
EDIT:
What if I wanna debug the remote AJAX app instead?

Add Access-Control-Allow-Origin: * header to your response. It's depends on what backend or server side you are using. There are some reference:
HTTP Access Control
Enable CORS in Apache
Website about "enable cross-origin resource sharing"

How to test GET/POST or better way?

I am writing an app that will send POST/GET requests from a remote client to a server. As a way to test and also educate myself I was trying to make these requests by writing a simple html file that resides on my desktop with a form that would POST to a server side php file. I also tried using ajax style requests or XMLHttprequests independent of and connected to a form but I received an error in the console:
Cross Origin Request Blocked
For all attempts form or no form. I have read that this is because I am making the request from FILE:// and this is not allowed by browsers unless CORS is enabled in some way. I have also read that using a webserver to host the file might fix the problem but I don't understand what is meant by webserver (separate or same domain? lamp, xammp, mamp?) and I am not interested in overriding security (allowing cors with headers) if I am eventually going to have to find a secure way when it goes live anyway.
As I said I am really just trying to test and I would like my html files to communicate with the server-side php from another machine instead of just putting all files together in the same domain/folder. Is there a way to do this using html/javascript or Websockets or anything html5 has to offer that might be useful?
code examples are welcome but if anyone could help me grasp this concept better it would be greatly appreciated. I am a noob XD
I am open to a better approach entirely if one exists, the only constraint I have is that everything on the UI/Client end is going to be written in html/javascript but I can utilize either or both intel XDK api and Cordova api as well.
Please help and thank you.

If you need to send some HTTP requests to test the server-side of your app I would strongly recommend you use an HTTP client like Fiddler:
http://www.telerik.com/fiddler
Also, read this:
GUI HTTP client
A desktop-based client will have a nice GUI with plenty of features to tweak, save, send, resend your requests.

One thing you can do is use pythons SimpleHTTPServer to serve the html file. Then when you go to your browser and go to 127.0.0.1:8000 the origin will be the same.
You can run the server by going into the directory that has the html file and running the command python -m SimpleHTTPServer 8000. This will serve the content of that directory on port 8000 and it should allow the requests to be made without a CORS exception.
Heres the documentation https://docs.python.org/2/library/simplehttpserver.html

I recommend that you disable the same-origin policy in your browser in order to test cross domain AJAX request from a local file.
For example, with Google Chrome on Windows you can disable this by launching chrome with the following command :
C:\Users\YOUR_USER\AppData\Local\Google\Chrome\Application\chrome.exe --allow-file-access-from-files --disable-web-security
Together, both of these flags will allow you to test cross-domain ajax requests from a local file. These flags are relevant across Mac, Windows and Linux.

This is not on how to write the requests but you can bypass writing those if you are using the latest version of the Intel XDK. If you go to the services tab in the latest version of the Intel XDK, there is a service by the name of Sandbox Explorer. It has a GET and POST method UI. Just plug in the URL and you will see the response immediately. You can use this to debug the server that you are writing. Once you have the server returning the right response, create a data binding to use the GET API in your client side javascript or html code. Cross origin is taken care of.

Is there a way to bypass Javascript / jQuery's same origin policy for local access?

Trying to use ajax, getJSON, and functions like that to fetch an external URL from a local (non-server) development computer. Is there a way to bypass the same origin policy, so that I can test locally, instead of having to upload to a server?

Here's the simple answer: chrome --disable-web-security
From the source code (chrome_switches.h):
// Don't enforce the same-origin policy. (Used by people testing their sites.)
const char kDisableWebSecurity[] = "disable-web-security";
I wanted to use jquery.js to send AJAX calls to a Google Apps python server running on port 8080. Just for testing, I wanted to run the browser and the server on the same machine.
I don't understand all the security nuances, but for temporary development it seems like a reasonable workaround. So long as I only use chrome for testing with this flag, it shouldn't be a problem.
Here's the whole command for Mac OS X:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security

We had the same need when developing our web app. Here's how we did it:
The browser and the server communicate only through JSON.
All the HTML is rendered in the browser using PURE (our JS template engine).
The browser code is developed locally like this:
We add a host parameter in the url of the app:
http://localhost/app.html?host=test.beebole-apps.com
In production, the JSON are sent to the server with a POST.
But here the function in charge of the ajax call will react to the host parameter and make a JSONP injection(GET) instead.
<script src="http://test.beebole-apps.com/?callback=f2309892&json={...}" />
f2309892 is a temporary function, with a random name, that points to the method that will handle the response
json is the JSON we send to the server
It means you will need some cooperation from the backend to serve you the json wrapped in a callback function like:
f2309892( /*the json here*/ );
Except a size limitation(you can't send a big JSON to the server with a GET) it works like a breeze.
An other advantage is you can call all the different systems(development and test) from the same localhost.

There are different ways to get around this, depending on which browser you're using for development. For example:
In Firefox (Gecko), set security.fileuri.strict_origin_policy to false
In Chrome, start the browser with the option --allow-file-access-from-files
References: Firefox, Chrome

Without touching the server -
The quickest and easiest way to bypass the same origin security policy in Firefox is the install the Force CORS add-on. This works with any service by inserting the proper headers into every response.
https://addons.mozilla.org/en-US/firefox/addon/forcecors/

Since this is a development issue and not a end-user/functionality issue, rather than focusing on getting AJAX to cross domains get your development environment set up as a proxy to fetch the most recent data from the production servers. This is actually really easy to do.
You'd need to set up a web server in your dev environment (if it doesn't have one already), and then configure the server to respond to 404 requests by fetching and then echoing production data. You can set up your server so that only the AJAX data files are picked up (otherwise, it will be confusing to debug other files if production assets start showing up on your development pages). So if http://dev.myserver.com/data/json/mydata.json is missing, your 404 script will get http://prod.myserver.com/data/json/mydata.json and echo it to the client. The nice thing about this set-up is that you can use mock data very easily: if the file is there in your dev environment, your AJAX script will get that; but if you then erase or rename that file, you'll get the production data instead. This feature has been so useful I can't recommend it enough.
If you're working with XML, I'd recommend duplicating the HTTP headers in the 404. If your 404 process responds with a Content-Type of text/html, you won't get any responseXML to parse.

try this (php curl ayax cross domain - by google):
http://www.iacons.net/writing/2007/08/02/ajax-cross-domain-proxy/
http://www.phpfour.com/blog/2008/03/cross-domain-ajax-using-php/
http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html

I had that problem, too, using Chrome and the --allow-file-access-from-files option didn't really help. Back to the script my server needed to return, I added these headers to the response and it worked fine :
'Access-Control-Allow-Origin: http://localhost/'
and another one for allowing a sort of key exchange
'Access-Control-Allow-Headers: X-KEY'

localhost is not allowed to use in CORS http://code.google.com/p/chromium/issues/detail?id=67743 use lvh.me instead