Jan Mikoláš
Glossary
Web application
A web application connects a user interface, application rules and data through web standards. It can be server-rendered, a client application built on an API, or both within one product.
Short definition
An interactive product available through the web.
A web application offers functionality, not just static content: a user can sign in, search, place an order, manage an account or work in an internal administration interface. The frontend creates the interface, the backend processes the rules, and data is stored in a database or handled through other services.
Not every web application is a single-page application, and not every interactive page needs extensive JavaScript. Server-side rendering, traditional forms, an API and a separate frontend are technical choices based on the needs of the product and its users.
The problem it solves
It makes a product available to multiple users through a browser
Web standards allow an application to be used without installing a traditional desktop client, but do not remove the need to design data and security correctly.
- an online store with a catalogue, orders, payments and customer accounts
- an internal system for inventory, finance, customer support or administration
- SaaS with users, organisations, roles and tenant isolation
- a customer portal built on APIs and integration services
- a booking system or work tool accessible from multiple devices
Practical example
An online store as one product with multiple parts
The public catalogue allows customers to search for products. A customer signs in, adds items to the cart and places an order. An administrator manages prices and inventory. The backend works with a database, payment gateway, carrier and possibly a search index.
A cache or Elasticsearch can speed up reads, but orders, payments and inventory changes remain in the transactional source of truth. The user should see a state the system has actually confirmed, not merely a value changed optimistically in the browser.
How it works
From opening a URL to changing data
This simplified diagram shows functional components that may run together or separately.
- The user opens a URL Through DNS and HTTPS, the browser obtains HTML, CSS, JavaScript or the initial application data.
- The frontend creates the interface On the server or client, it displays content, navigation and controls according to the current state.
- The user takes an action A form or JavaScript sends an HTTP request with a specific intent.
- The backend processes the operation It verifies identity, permissions, data and business rules, then works with the database or services.
- The result becomes visible The response updates the interface; secondary jobs such as email or synchronisation can continue outside the request.
Important parts
The interface, rules, data and operations form one product.
The division between technologies varies, but the responsibilities remain similar.
Frontend and backend
The user interface and server logic can live in one monolith or be deployed as separate applications.
HTTP and URLs
The web uses URLs for addressing and HTTP for requests and responses; HTTPS protects communication in transit.
Data and cache
The database is the source of truth for business data, while the cache is an optimisation layer with its own expiration and invalidation rules.
Identity and permissions
Sign-in establishes identity; server-side authorization decides whether a specific operation on a specific record is permitted.
Rendering and availability
Server-side rendering, client-side rendering and PWAs are different approaches. Availability and behaviour during failure are what matter.
Benefits and limitations
Browser access does not remove product complexity.
Benefits
- access through a standard browser from multiple devices
- shared data and rules for users, administration and integrations
- use of HTTP, URL, HTTPS and web infrastructure standards
- the option to choose a separate frontend or a straightforward server-rendered product
Common mistakes
- assuming that a web application must be a SPA
- leaving authorization solely to the frontend
- treating a cache or search index as the source of truth for orders
- adding services, queues and APIs merely because they appear modern
When it makes sense
For products that need shared functionality and data on the web.
A web application is a natural fit for e-commerce, portals, booking systems, administration tools or SaaS where multiple users work with shared data and processes. Not every part needs to be a separate service; what matters is that the product can be developed and operated safely.
Simple public content can be a static website. If device capabilities, offline work or deep system integrations are the primary goal, a native application or a combination of clients over a shared backend may be more appropriate.
What to consider
Quality depends on every application layer.
A user problem often surfaces only at the boundary between the interface, network, backend and data.
- design clear error and loading states for users
- protect sessions, identity and permissions on the server
- keep data and transactions as the source of truth and invalidate caches deliberately
- measure availability of the HTTP entry point, backend and key integration flows
- choose the architecture according to product complexity and team capabilities
Common questions
Common web application boundaries
Is a web application the same as a web page?
Not quite. A page can contain only static content, while an application usually works with state, data and user actions. In practice, however, the boundary is not sharp.
Does a web application need a separate API?
No. A server-rendered application can use forms and the same backend modules. An API is appropriate when other clients or the product architecture genuinely need it.
Is a mobile application a web application?
Not necessarily. It can use the same backend and API, while a PWA is a specific type of application built on the web platform.
Is a database part of a web application?
Often yes at the system level. The application may also use APIs, caches, a search index and other separate services.
How I work with applications in practice
I develop e-commerce applications from the data model through integrations.
I draw on my experience with online stores when designing order flows, administration interfaces, backends, APIs and long-term operations.