Client-server computing separates a requester's role from the service that answers it. A browser requesting a web page is a client; the web application receiving that request acts as a server. These are software roles, so they do not have to run on different physical computers.
The distinction helps you understand where website data comes from and where to investigate a failure. It does not mean the client has unrestricted access to everything stored on the server.
Follow one page request
Consider a visitor opening a product page. The browser sends a request to the website. The server may read application data, construct a response and return it; the browser displays the result and may request additional resources. A cached response can avoid repeating some of that work. MDN's client-server overview explains this request-and-response model.
A website's application server may itself become a client when it requests records from a database or calls a payment service. The roles depend on the interaction, not on a permanent label attached to the machine.
What belongs on each side?
- Client: presents the interface, collects user input and sends requests.
- Server: handles requests and applies the service's rules, including checks on access and submitted data.
- Protocol: defines how the two exchange messages. Web applications commonly use HTTP; other services use other protocols.
For example, a browser can display an order form, but the server should verify the submitted price and the user's authorization before accepting an order. A client-side check can help the interface; it cannot establish that an untrusted request is valid.
One computer or many?
A developer can run a browser and a local web server on one laptop. A public application may distribute its web, application and database services across several systems. Conversely, one server can answer many clients. The client-server model describes their relationship, not a required hardware arrangement.
This also explains why buying a larger server does not automatically fix every slow page. The delay may be in the client, the network, the application, a database request or another service on which the application depends.
Use the model to narrow a problem
When a request fails, record what the client requested and what response it received. Check whether other clients see the same failure, whether the server received the request, and whether a dependency failed after that. A browser error alone does not identify the broken component.
Start with one reproducible request rather than changing several systems at once. That gives the person investigating a concrete path to follow from client to service and back.
