Creating Web Apps  «Prev  Next»

Lesson 8Executing components of applications
Objective Describe the architectural considerations when developing Web sites and applications.

Application Architecture for Web Sites and Applications

Application architecture defines how components of a web system are structured, where processing occurs, how data flows, and how security and scalability are enforced. Whether building a simple content-driven website or a complex SaaS commerce platform, architecture determines performance, maintainability, and long-term viability.

Modern web systems are no longer confined to a single server. They may operate across cloud regions, edge networks, microservices, and third-party APIs. Therefore, architectural decisions must balance user experience, security, deployment model, scalability requirements, and operational constraints.

Web Sites vs Web Applications

A traditional website primarily delivers content — articles, product descriptions, marketing pages — often supported by a content management system (CMS). A web application introduces persistent state, authenticated users, transactions, analytics, and workflow processing.

Architectural complexity increases when moving from:

Commerce systems, SaaS dashboards, and regulated enterprise platforms require deliberate architectural planning beyond simple hosting decisions.

Client-Side vs Server-Side Execution

One of the foundational architectural decisions involves determining where components execute.

Server-Side Components

Components that must be shared, persistent, or secure belong on the server. These include:

Server-side logic ensures consistency across sessions and prevents tampering by clients.

Client-Side Components

Client-side execution improves responsiveness and reduces server load. Suitable client-side responsibilities include:

However, client-side logic must never be trusted for security-critical operations.

Key Architectural Considerations

1. Server Location and Deployment Model

Deployment choices influence performance and control. Options include:

Small businesses often prioritize cost efficiency and rapid deployment. Regulated industries may require strict data locality and compliance controls. Enterprise systems may distribute workloads across regions for redundancy and latency optimization.


2. Performance and Response Time

If rapid feedback is essential (e.g., interactive dashboards or real-time collaboration), partial processing may shift to the client or edge layer. Conversely, thin clients or low-powered devices require heavier server-side computation.

Performance strategies include:

3. Capacity Planning

Architects must evaluate both client and server capacity. Modern SaaS commerce platforms often leverage distributed infrastructure to absorb traffic spikes. Serverless computing may offload burst processing without maintaining dedicated hardware.

In headless or composable commerce architectures, API-based services scale independently — product catalog services separate from payment services, for example.

4. Security Architecture

Security considerations permeate every architectural decision. These include:

In payment ecosystems, secure backend orchestration ensures that sensitive credentials remain isolated from the browser.


5. Reuse and Maintainability

Reusable components reduce long-term cost. Modern frameworks promote modular services, API contracts, and separation of concerns. Legacy server APIs such as NSAPI and ISAPI optimized performance but sacrificed portability.

Today, portability is achieved through standardized protocols (HTTP, REST, GraphQL) and containerized deployment.

Legacy Technologies and Their Evolution

CGI and SSI were early mechanisms for server-side execution. Their primary limitation was performance: each request required process spawning and repeated initialization. Native server APIs improved efficiency but introduced vendor lock-in.

Modern application servers and runtime environments address both issues through persistent processes, non-blocking I/O, and standardized interfaces.

Modern Commerce Architecture Context

In SaaS commerce environments, much infrastructure is abstracted. However, architectural decisions remain critical:

Headless and composable systems separate frontend presentation from backend services, increasing flexibility but requiring disciplined API design and infrastructure coordination.

Architectural Patterns in Practice

Common architectural models include:

Each model carries trade-offs in complexity, cost, and operational overhead. Architectural decisions should align with organizational size, compliance needs, growth expectations, and performance targets.

Conclusion

Application architecture for web sites and applications requires deliberate evaluation of execution location, scalability, performance, security, deployment model, and maintainability. The decision of where components execute — client, server, edge, or distributed services — affects every aspect of system behavior.

While early web systems relied on CGI scripts and native APIs, modern architectures operate across cloud infrastructure, APIs, analytics platforms, CMS integrations, and distributed networks. Regardless of technological evolution, the guiding principle remains consistent: place each component where it can operate securely, efficiently, and sustainably within the overall system design.


SEMrush Software 8 SEMrush Banner 8