Architecture Paradigm Client Server
Document client-server versus peer-to-peer responsibilities, API contracts, and version-skew strategy while designing web or mobile products.
Overview
architecture-paradigm-client-server is an agent skill most often used in Build (also Validate scope) that applies client-server and peer-to-peer paradigms with documented contracts and version-skew planning.
Install
npx skills add https://github.com/athola/claude-night-market --skill architecture-paradigm-client-serverWhat is this skill?
- Applies client-server architecture for web and mobile apps talking to centralized backends
- Covers peer-to-peer and offline-first synchronization when decentralization matters
- 4 adoption steps: define responsibilities, document contracts, plan version skew, address sync/consistency
- Tags include distributed-systems, paradigm-implementation, and offline-first usage patterns
- Low complexity pattern skill with ~600 estimated tokens and fast model hint
- 4 numbered adoption steps from responsibilities through version skew
- Estimated 600 tokens with low complexity rating in skill metadata
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You are splitting features between client and server without clear APIs, auth boundaries, or a plan for mismatched app versions.
Who is it for?
Solo builders designing web or mobile apps with REST or similar backends, optional offline-first sync, or formal trust boundaries.
Skip if: Pure static sites with no API, or teams that already maintain a complete architecture decision record with no open boundary questions.
When should I use this skill?
Designing systems with centralized backend services, trust boundaries, or offline-first sync for web or mobile apps.
What do I get? / Deliverables
You get a structured paradigm write-up with responsibilities, contracts, and version negotiation so implementation and sync strategies stay consistent.
- Client versus server responsibility split
- Documented API, schema, and authentication contracts
- Version-skew and offline-sync strategy notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Implementation architecture is owned during Build, but the same paradigm framing applies when scoping APIs earlier—backend is the canonical shelf for centralized service design. Trust boundaries, authentication flows, and API evolution sit squarely in backend system design rather than pure UI polish.
Where it fits
Decide whether heavy logic stays on device or moves to a centralized API before prototyping.
Write authentication flows and schema contracts the mobile client must honor.
Align web client capabilities with server feature flags and content negotiation headers.
Plan API semver and deprecation when older app versions remain in the wild.
How it compares
Use this pattern skill for responsibility and contract framing—not as a drop-in IaC or deployment generator.
Common Questions / FAQ
Who is architecture-paradigm-client-server for?
Indie developers and small teams architecting client-server or P2P-friendly products who want the agent to follow a repeatable distributed-system checklist.
When should I use architecture-paradigm-client-server?
Use it in Validate when scoping APIs and sync strategy, and in Build when defining backend boundaries, authentication, and client version negotiation before implementation.
Is architecture-paradigm-client-server safe to install?
It is documentation-style guidance with no bundled secrets; still review the Security Audits panel on this Prism page before adding any third-party skill to your agent.
SKILL.md
READMESKILL.md - 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. ## 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 TLS for all data in transit. Implement authorization policies, rate limiting, and detailed telemetry for every endpoint. ## Key Deliverables - An Architecture Decision Record (ADR) that covers the roles of clients, servers, and peers, defines the trust boundaries, and outlines deployment assumptions. - Formal API or protocol specifications, along with a suite of compatibility tests. - Runbooks detailing the coordination required for rollouts, such as client release waves, backward-compatibility support, or operational procedures for a peer-to-peer network. ## Risks & Mitigations - **"Chatty" Clients**: - **Mitigation**: A client making too many small requests can lead to poor performance. Consolidate API calls using patterns like the Façade or Gateway, and implement caching strategies on the client or at the network edge. - **"Thick" Clients with Duplicated Logic**: - **Mitigation**: When clients contain too much business logic, it often becomes duplicated and out-of-sync with the server. Share validation logic by packaging it in a common library or move the rules definitively to the server. - **Peer-to-Peer Data Conflicts**: - **Mitigation**: In a peer-to-peer model, data conflicts are inevitable. Design formal conflict resolution strategies (e.g., CRDTs, last-write-wins) and consensus mechanisms from the beginning. ## Concrete Components These vocabulary items name the concrete tools and abstractions that show up when the paradigm is implemented. They are not required dependencies and they are not part of the skill's ``tools:`` frontmatter (which is reserved for Claude Code tool restrictions). Use this list to disambiguate during architecture discussions. - ``api-contract-generator``: produces machine-readable OpenAPI/RPC contracts the client and server share - ``networking-debugger``: captures request/response traces for diagnosing latency, retries, and timeout issues