Web Application

Web Application — questions and answers

What does it mean for a web application to be stateful, and why does that complicate development?

A stateful application remembers information about each user between requests—what they've added to a cart, where they are in a multi-step process, their preferences. This requires storing session data somewhere (in cookies, server memory, or a database) and ensuring that data remains consistent when users open multiple tabs, refresh pages, or when the application runs across multiple servers. Stateless applications are simpler because each request contains everything needed to process it.

How do single-page applications differ from traditional multi-page web applications in how they're built?

Single-page applications load one HTML page and rewrite content dynamically using JavaScript as users interact, rather than requesting new pages from the server. This requires a different architecture: the backend typically provides a REST or GraphQL API returning JSON, while the frontend framework (React, Vue, Angular) handles rendering, routing, and state management in the browser. The initial build is more complex, but subsequent interactions feel faster because only data moves across the network.

Why do web applications need to handle authentication differently from authorisation?

Authentication verifies who someone is—checking credentials, issuing tokens, maintaining sessions. Authorisation determines what that authenticated user is allowed to do—which records they can view, which actions they can perform. Confusing the two creates security holes: a user might authenticate successfully but then access data they shouldn't. Proper applications check permissions at every operation, not just at login, and enforce rules both in the interface and on the server.

What happens when two users try to update the same record simultaneously?

Without concurrency control, one user's changes overwrite the other's—a lost update. Applications handle this through optimistic locking (detecting conflicts when saving and asking users to reconcile), pessimistic locking (preventing others from editing while one user has the record open), or last-write-wins (accepting that conflicts are rare enough to ignore). The right approach depends on how often conflicts occur and how critical data accuracy is.

Why might a web application work perfectly on a developer's machine but fail in production?

Development environments often differ from production in ways that hide problems: smaller datasets that mask performance issues, different software versions, relaxed security settings, or missing environment variables. Network latency, load balancer behaviour, caching layers, and firewall rules only exist in production. Proper deployment processes use staging environments that mirror production configuration and automate testing across realistic conditions before release.

What makes WebSocket connections useful for certain web applications, and what trade-offs do they introduce?

WebSockets maintain a persistent two-way connection between browser and server, allowing the server to push updates instantly rather than waiting for the browser to poll. This suits chat applications, live dashboards, and collaborative editing. The trade-off is complexity: the server must manage thousands of open connections, handle reconnection logic when networks drop, and scale differently than stateless HTTP applications. Not all hosting environments support them well.