How The Web Works (And How It Is Changing) 2013-01-01
When I started web development, I frequently heard other developers talk about the client, the server, and the database. At the time, I had no idea what that stuff was all about. And I frequently hear questions from other newbies as to what they are talking about. So, I decided to write an article that explains the web, the way developers see it -
The web is made up of four components - (1) the server, (2) the client, (3) the database, and (4) the code.
The Client -
The client is the computer on which the user visits a web page. Your computer is being a client right now, as you're seeing this web page. Every web page lives on a server. When you visit a web page, the client sends a request to the server. The server responds by sending a web page to the client, and then you can see the web page.
The Server -
The server is the machine on which the web page lives. As described previously, when a client tries to visit a web page, the client sends a request to the server. The server responds by sending back a web page. If you use a framework like Rails or Django, the server is also where most of the code is run. For example, when a user clicks on a button (the click is registered as an 'event') on a web page, the client sends a message to the server. Based on this, the server may run some code (sometimes called 'event handler' code), and send some output to the client.
The Database -
A database is used to store site-related data. For example, Facebook uses a database to store information about their users, and their users' posts. Twitter uses a database to store users and their tweets. The database lives on the server, and sites interact with their databases via their code.
The Code -
The code generally lives on the server. It does things like modifying the database, and making a site more interactive. For example, when a user creates a Twitter account, the client sends a message to the server. The server then runs some code, which adds the user to the database, and sends the user's profile page to the client. The next time the user tries to login, the client tells the server, the code on the server checks the database for the same user data, and if it exists, the user's profile page is sent back to the client.
How The Web Is Changing -
Code On The Client -
Database Cache On The Client -
As sites are trying to be more and more interactive and responsive, it has become necessary for them to start using a database cache on the client. This allows them to perform database actions faster, because they don't have to wait for the server.
Latency Compensation -
This might be a Meteor-only thing, but I decided to cover it anyway. As mentioned previously, sites have started using a database cache on the client. But, they still maintain a database on the server. Why two databases? With a database cache on the client, when a client performs an action, they get to see it completed immediately, without waiting for the server. Later, when the client and server have synchronized, if the server doesn't agree with the client's data, the client's data is patched up. This lets a site be interactive, and be synchronized between clients.
Responsive Design -
As more and more smartphones and tablets are capable of web-browsing, sites are required to be mobile browser friendly. By designing a site responsively, it can change its layout based on screen size and orientation.
What This All Adds Up To -
Since code is moving to the client, this means sites can be more interactive. They can respond to events faster, because they don't have to send messages to the server and wait for a response. Latency compensation allows users to see their database actions completed immediately, and still be in sync with the server and other clients. Since both the database and code are on the client, we can say apps are moving to the client. And this means the web is becoming more interactive.