A fat client is a computer, in client–server architecture or networks, that typically provides rich functionality independent of the central server. Originally known as just a "client" or "thick client," the name is contrasted to thin client, which describes a computer heavily dependent on a server's applications. A fat client may be described as having a rich user interaction. A fat client still requires at least periodic connection to a network or central server, but is often characterised by the ability to perform many functions without that connection. In contrast, a thin client generally does as little processing as possible, relying on access to the server each time input data needs to be processed or validated.
Introduction
The designer of a client–server application decides which parts of the task should be executed on the client, and which on the server. This decision can crucially affect the cost of clients and servers, the robustness and security of the application as a whole, and the flexibility of the design to later modification or porting. The characteristics of the user interface often force the decision on a designer. For instance, a drawing package could require download of an initial image from a server, and allow all edits to be made locally, returning the revised drawing to the server upon completion. This would require a thick client and might be characterised by a long delay to start and stop, but quick to edit. Conversely, a thin client could download just the visible parts of the drawing at the beginning and send each change back to the server to update the drawing. This might be characterised by a short start-up time, but a tediously slow editing process.
History
The original server clients were simple text display terminals including WyseVDUs, and thick clients were generally not used until the increase in PC usage. The original driving force for thin client computing was often cost; at a time when CRT terminals and PCs were relatively expensive, the thin-client–server architecture enabled the ability to deploy the desktop computing experience to many users. As PC prices decreased, combined with a drop in software licensing costs, thick client–server architectures became more attractive. For users, the thick client device provided a more-responsive platform and often an improved Graphical User Interface than could be achieved in a thin client environment. In more recent years, the Internet has tended to drive the thin client model despite the prodigious processing power that a modern PC has available.
Centrally hosted thick client applications
Probably the thinnest clients, sometimes called "ultra thin," are remote desktop applications, e.g. the X Window System, Citrix products, and Microsoft's Terminal Services, which effectively allow applications to run on a centrally-hosted virtual PC and copy keystrokes and screen images between the local PC and the virtual PC. These ultra-thin clients are often used to make available complex or data-hungry applications which have been implemented as thick clients but the true client is hosted very near to the network server.
Advantages
Lower server requirements. A thick client server does not require as high a level of performance as a thin client server. This results in drastically cheaper servers.
Working offline. Thick clients have advantages in that a constant connection to the central server is often not required.
Better multimedia performance. Thick clients have advantages in multimedia-rich applications that would be bandwidth intensive if fully served. For example, thick clients are well suited for video gaming.
More flexibility. On some operating systems software products are designed for personal computers that have their own local resources. Running this software in a thin client environment can be difficult.
Using existing infrastructure. As many people now have very fast local PCs, they already have the infrastructure to run thick clients at no extra cost.
Higher server capacity. The more work that is carried out by the client, the less the server needs to do, increasing the number of users each server can support.
