A web application, or web app, is a program which interacts with users through a web browser over a network. While a web server can respond to requests with static files, a web application typically handles requests dynamically by programatically building the response. Web applications are the foundation of interactive web sites. They are sometimes referred to less accurately as a rich internet applications.
Web applications consist of several components or tiers. Each is often thought of as a layer, with one built on top of another. At a bare minimum there are two tiers: the client (web browser) and the server (web application). All components, of course, must run on some form of operating system, and therefore the OS is generally not counted as a layer. Here the various possible web application tiers are described from the bottom up.
Most web applications are built with dynamic data. This data is usually stored in a database server, or sometimes another form of long-term storage. Some data is expected to change often, such as in a shopping cart or discussion board. Other data may change less frequently, such as maps or or help documentation. The type of data storage chosen is dependent on the format of the data, the frequency of its change, and how it's going to be used.
Web applications with large amounts of data often find the database to be the primary server-side bottleneck. The selection and configuration of database servers have a large impact on performance and scalability. Distributed and cached data storage are often good choices for web sites which expect high growth.
 Web Application Server
The core of a web application is the application server. The server handles requests from the web browser and builds the appropriate response. A web application can directly listen for HTTP requests. More often, however, a generic web server, such as Apache's httpd, listens for requests and hands them to the appropriate application. Today, the server component of web applications are most often written in Java, Perl, PHP, Python, or .NET.
Web applications themselves can be built of multiple layers. Complex systems might separate business logic and transaction servers from the content display components. This is often the case with workflow and financial transaction systems. An added benefit of separate business logic or other core servers is their use for other systems. A workflow transaction system, for example, might be shared between a web site and rich client application. This promotes code reuse and allows developers to focus on specific tasks.
Some runtime environments, such as Java's web containers and Python, allow web applications to run indefinitely. Others, such as PHP, treat each request independently with a completely new environment. This greatly affects web application architecture, in that some components may be persisted by the environment and shared by requests.
 Web Browser
The top layer of most web applications is the web browser, which directly interacts with the user. This is the one component over which web application developers have the least control, as on a public web server any version of any web browser may try to connect and interact. Therefore standards for public web sites are extremely important. Browsers need to support common standards so they can all be used with the widest range of web sites. And web applications need to support common standards so they don't alienate any segment of potential users.
Between the layers there are various protocols and libraries used to communicate. The web server connects a database locally, often through sockets, or over a network between computers. Web servers might interact with each other or with application servers through basic networking, like TCP/IP, or higher level protocols like RPC. Web servers communicate with web browsers using the HTTP protocol.
While a typical client application can retain its state while continually waiting for user input, web applications are inherently stateless due to the HTTP protocol. Each request from any user is handled independently. To overcome this limitation cookies are often used to keep track of user sessions. With each page request the active session can be checked to get user-specific information.
 Best Practices
 Design Patterns
- Web application frameworks can provide a foundation for site structure, workflow, code organization, and common tasks.
- Model-View-Controller, used often in desktop applications, can also be applied to structure web applications.
- Object-relational mapping aids in the persistence of business objects in a relational database.
- User interface and interaction
- AJAX, when used properly, can be very affective in improving user interaction and engagement.
- Autocomplete textboxes assist users in filling input boxes with previously used values.
- Dialog boxes, just as with desktop applications, present a smaller window over a page.
- Progress bars, when implemented with AJAX, can continually update with a server's status.
- Progressive loading of content lets users see content as it's retrieved, giving them quicker feedback with large sets of data. This is accomplished using AJAX.
- POST-Redirect-GET resolves issues with reloading and bookmarking posted pages.
- Caching can be used at many levels to improve performance.
- When one database server can not handle the load, database replication can be leveraged. Web applications can be programmed to take full advantage of a replicated database environment.
Main article: Web application/Security
Web applications which exist on the public internet should never trust user input, or any input from the client application. Malicious code may connect to a web application server from any other computer, with or without the owner's knowledge. Any layer of an application may be a security risk, and any input may be an attack vector:
- HTTP request headers may attempt to manipulate a web server or application runtime.
- Unexpected requests for files may download source code or secure files.
- HTML form submissions may contain executable code.
- Cache dynamically generated content when possible. Pages that rarely change, for example, don't need to be regenerated on every request. Consider caching earlier in the request handling when possible, such as at the web server layer or earlier using a proxy server. Also set the cache values of the HTTP headers to inform web browsers and intermediate servers what they may cache.
- Leverage features of the HTTP protocol, such as expiration headers. Client browsers, proxy servers, and web accelerators can use this information to optimize performance.
- Compress network traffic when possible, such as with gzip. When implemented properly this will often be transparent to custom programming and to users. Apache httpd, for example, has a module which will automatically compress files by MIME type.
- Consider spreading requests across multiple servers, i.e. load balancing. A simple round-robin approach might be sufficient in many situations, and can be implemented with a simple generic web server. An advanced load balancer will monitor the load of each server and distribute it appropriately.
- Consider specialized servers for certain requests, such as multimedia.
- Consider database replication. See programming for database replication for additional considerations.
- Run tasks which don't need to execute during a page load in the background. This is most often accomplished with scheduled tasks, such as cron jobs. Offloading background tasks to secondary servers can additionally enhance performance.
- Leverage platform and language performance characteristics
- Generate optimized web pages, as the performance of page rendering factors into the perceived performance of web applications.
 Case Studies
Obviously there are too many web applications to list and analyze. A few notable web apps include