architecture-paradigm-client-server

# The Client-Server and Peer-to-Peer Paradigms ## When to Employ This Paradigm - For traditional applications that have centralized services, such as web or mobile clients communicating with backend APIs. - For systems exploring decentralized or "offline-first" capabilities that rely on peer-to-peer synchronization. - To formally document trust boundaries, client-server version negotiation, and API evolution strategies. ## When NOT To Use - Systems with no network boundary between UI and logic (use `archetypes:architecture-paradigm-modular-monolith`) - Choosing among paradigms in the first place (use `archetypes:architecture-paradigms`) ## Adoption Steps 1. **Define Responsibilities**: Clearly delineate which logic and data reside on the client versus the server, with the goal of minimizing duplication. 2. **Document the Contracts**: Formally document all APIs, data schemas, authentication flows, and any capability negotiation required for handling different client versions. 3. **Plan for Version Skew**: Implement a strategy to manage different client and server versions, such as using feature flags, `Accept` headers for content negotiation, or semantic versioning for APIs. 4. **Address Connectivity Issues**: If the application is not purely client-server, design for intermittent connectivity. This may involve implementing offline caching, data synchronization protocols, or peer discovery and membership services. 5. **Secure All Communications**: Enforce the use of TL...