/wiki / backend-nd-frontend

bff-pattern

2026-09-19T00:00:00.000Z

The Problem

One backend serving web, iOS and Android ends up bloated — how do you tailor backend responses for each front end without duplicating logic?

Formal Definition

Per Wikipedia: “The Backend for Frontend pattern provides a separate backend service per front-end type that aggregates and shapes data for that UI.”

Explanation

Like a concierge for each hotel wing — web concierge and mobile concierge both call the same kitchens but pack the tray differently.

How It Works

Identify front ends needing different shapes
Create BFF service per front end
BFF calls downstream microservices
BFF aggregates and trims payload
Front end calls only its BFF

Visual Explanation

Semantic Network

Key Properties

Reduces over-fetching for mobile
Lets each UI evolve independently
Adds operational overhead of extra service
Should not contain business logic

Real-World Example

 # BFF aggregates
def get_home(user_id):
    profile = users_svc.get(user_id)
    feed = feed_svc.get(user_id)
    return {'profile': profile, 'feed': feed[:10]}

Connections

Built from: Client-Server Model — BFF is a specialized server
Related: Back End — BFF is a back-end kind
Related: Front End — BFF serves a specific front end
Builds into: Scalability — avoids chatty mobile calls

Edge Cases & Gotchas

BFF per pixel — creating BFF per screen not per platform
Leaking domain logic into BFF — becomes monolith

business-logic

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[business-logic]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of business logic.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Business Logic

Connections

Related: Index — auto stub for singleton [[business-logic]] from wiki/backend-nd-frontend/back-end.md

Edge Cases & Gotchas

To be written.
To be written.

cors

2026-09-19T00:00:00.000Z

The Problem

Browser blocks fetch from api.example.com when page is on app.example.com — why does the same code work in curl but not in browser?

Formal Definition

Per Wikipedia: “CORS is a browser security mechanism that blocks cross-origin requests unless server sends Access-Control-Allow-Origin headers.”

Explanation

CORS is the bouncer checking the guest list — same-origin is allowed in, cross-origin needs explicit invite from server.

How It Works

Browser sends Origin header
Server checks allow list
Server replies with ACAO header if allowed
Browser enforces — blocks if missing
Preflight OPTIONS for non-simple requests

Visual Explanation

Semantic Network

Key Properties

Only enforced by browsers, not by curl
Simple GET/POST may skip preflight
Credentials need explicit Allow-Credentials

Real-World Example

fetch('https://api.example.com/data', {mode: 'cors'})
  .then(r => r.json())

Connections

Built from: HTTP API — CORS protects HTTP APIs
Related: Client — client triggers CORS
Related: Server — server configures CORS
Contrasts with: API — API without browser has no CORS

Edge Cases & Gotchas

Wildcard * with credentials fails — must list origin
Caching preflight without Vary: Origin causes leaks

data-access-layer

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[data-access-layer]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of data access layer.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Data Access Layer

Connections

Related: Index — auto stub for singleton [[data-access-layer]] from wiki/backend-nd-frontend/back-end.md

Edge Cases & Gotchas

To be written.
To be written.

high-availability

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[high-availability]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of high availability.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for High Availability

Connections

Related: Index — auto stub for singleton [[high-availability]] from wiki/backend-nd-frontend/back-end.md

Edge Cases & Gotchas

To be written.
To be written.

http-api

2026-09-19T00:00:00.000Z

The Problem

Front end and back end need a contract to talk — what format do requests and responses follow when a browser calls a server?

Formal Definition

Per Wikipedia: “An HTTP API is an interface that exposes application functionality over HTTP using verbs, paths, headers and status codes.”

Explanation

Think of an API as a menu in a restaurant. The front end orders by calling a URL, the back end cooks and returns JSON. HTTP just defines how the waiter carries the order.

How It Works

Client forms HTTP request with method and URL
Server routes request to handler
Handler runs business logic and queries data
Server formats JSON response with status code
Client parses response and updates UI

Visual Explanation

Semantic Network

Key Properties

Stateless — each request carries its own auth and context
Uses standard verbs GET POST PUT DELETE
Versioned via URL or header
Errors signaled via status codes

Real-World Example

# Minimal HTTP API call
import requests
resp = requests.get('https://api.example.com/users/1')
print(resp.status_code, resp.json())

Connections

Built from: Client-Server Model — API is the contract inside that model
Built from: API — specialization of generic API for HTTP
Related: Server — server implements the API
Contrasts with: Front End — front end consumes the API

Edge Cases & Gotchas

Forgetting pagination on list endpoints paginates in client not server
Mixing HTTP verbs — GET should not change state

presentation-layer

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[presentation-layer]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of presentation layer.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Presentation Layer

Connections

Related: Index — auto stub for singleton [[presentation-layer]] from wiki/backend-nd-frontend/front-end.md

Edge Cases & Gotchas

To be written.
To be written.

rest-principles

2026-09-19T00:00:00.000Z

The Problem

Teams argue whether an API is RESTful but have no checklist — what makes an API actually REST and not just JSON over HTTP?

Formal Definition

Per Wikipedia: “Per Fielding: REST is an architectural style with constraints — client-server, stateless, cacheable, uniform interface, layered system, code on demand (optional).”

Explanation

REST is like a vending machine — every button press is a self-contained request, the machine does not remember you, and every product has a clear address.

How It Works

Model resources as nouns with URLs (/users/42)
Use HTTP verbs for actions
Make each request stateless with auth header
Make responses cacheable with headers
Use hypermedia or links for discoverability

Visual Explanation

Semantic Network

Key Properties

Resource-oriented not action-oriented
Cacheable and layered
Uniform interface reduces coupling
Stateless simplifies scaling

Real-World Example

from flask import Flask
app = Flask(__name__)
@app.get('/users/<id>')
def get_user(id): return {'id': id}

Connections

Built from: HTTP API — REST refines HTTP API design
Related: API — REST is a style of API
Builds into: Scalability — stateless helps scale
Contrasts with: Full Stack — full stack may bypass strict REST

Edge Cases & Gotchas

Over-REST-ing — tunneling actions through POST /doThing breaks resource model
Ignoring idempotency — retrying POST creates duplicates

single-page-application

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[single-page-application]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of single page application.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Single Page Application

Connections

Related: Index — auto stub for singleton [[single-page-application]] from wiki/backend-nd-frontend/front-end.md

Edge Cases & Gotchas

To be written.
To be written.

user-interface

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[user-interface]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of user interface.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for User Interface

Connections

Related: Index — auto stub for singleton [[user-interface]] from wiki/backend-nd-frontend/front-end.md

Edge Cases & Gotchas

To be written.
To be written.

version-control

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[version-control]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of version control.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Version Control

Connections

Related: Index — auto stub for singleton [[version-control]] from wiki/backend-nd-frontend/full-stack.md

Edge Cases & Gotchas

To be written.
To be written.

Backend Nd Frontend -- Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Backend Nd Frontend — 7 concepts. Start here to navigate backend-nd-frontend.

Core Concepts

api — concept
back-end — concept
client — concept
client-server-model — concept
front-end — concept
full-stack — concept
server — concept

Mechanisms & How Things Work

Pages that explain processes/flows.

rest-principles — auto-linked orphan

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

scalability

2026-09-02T00:00:00.000Z

draft: true

The Problem

Auto-created stub for broken link [[scalability]] — needs human content.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation.

How It Works

To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example

Connections

Related: Index — auto stub, needs proper links

Edge Cases & Gotchas

To be written.

API

2026-04-12T00:00:00.000Z

The Problem

How does the front end communicate with the back end? How do different software components exchange data and functionality?

Core Idea

API (Application Programming Interface) is the interface through which software components communicate. In web development, APIs allow front end to request data and services from back end, typically over HTTP.

How It Works

Request: Front end sends HTTP request (GET, POST, PUT, DELETE) to API endpoint
Processing: Server processes request, applies business logic, accesses database
Response: Server returns data (JSON, XML) or status code
Consumption: Front end receives response and updates UI
REST/GraphQL: Common architectural styles for web APIs

APIs can also reduce front-end processing load using different back-end services for different front-end interfaces, known as the BFF (Backend for Frontend) pattern.

Key Properties

Defines how components interact
Standardized request/response format
HTTP-based for web (REST, GraphQL)
Can be internal or external (public APIs)
Authentication/authorization for security
Versioning for backward compatibility

Visual Explanation

Semantic Network

Connections

Builds into:

Front End — Consumes APIs to get data from back end
Back End — Implements and exposes APIs

Related:

HTTP — Protocol underlying most web APIs
HTTP Methods — Define API operations
BFF Pattern — API architecture pattern for front end optimization

Edge Cases & Gotchas

API versioning is critical when changing interfaces
Rate limiting prevents abuse
Error handling must be consistent
Documentation essential for API consumers

Back End

2026-04-12T00:00:00.000Z

The Problem

While users interact with the front end, the actual data processing, storage, and business logic must happen somewhere secure and centralized. How do you handle data management and processing behind the scenes?

Core Idea

Back end refers to the data management and processing layer behind the scenes. It handles data storage, business logic, and server operations. In the client-server model, the back end typically resides on the server.

How It Works

Data Storage: Manages databases and persists application data
Business Logic: Processes data according to application rules and workflows
Authentication & Authorization: Verifies user identity and permissions
API Implementation: Exposes endpoints for front end communication
Security: Protects against threats, validates input, encrypts sensitive data
Scalability: Handles increased load through clustering, caching, load balancing

In web development, back end includes server languages (PHP, Python, Ruby, Java, Node.js), databases, APIs, security practices, and system architecture.

Key Properties

Server-side execution, often remote from users
Handles data management and persistence
Implements business logic and rules
Exposes APIs for front end consumption
Must ensure security, authentication, authorization
Manages scalability and high availability
Includes database administration and data access layers

Visual Explanation

Semantic Network

Connections

Built from:

Server — Back end typically runs on servers
Business Logic — Back end implements business rules
Data Access Layer — Back end handles data access

Builds into:

Full Stack — Back end combined with front end forms full stack
API — Back end implements APIs for front end consumption

Related:

Server — Back end runs on servers
Front End — Complements back end as the client-side counterpart
Client-Server Model — Underlying architecture for front end/back end split
Scalability — Back end must handle growth in usage
High Availability — Back end must remain operational

Edge Cases & Gotchas

Server failures affect all users—high availability is critical
Database bottlenecks can cripple performance
Security vulnerabilities in back end expose all data
Must validate all input—even from trusted front ends

Client-Server Model

2026-04-12T00:00:00.000Z

The Problem

How do you structure an application where one side (client) handles user interaction while another side (server) manages data and processing? What is the fundamental architecture?

Core Idea

The client-server model is a distributed architecture where clients request services from servers. The client handles most user-facing tasks while the server manages data and logic. Front end maps to client, back end maps to server.

How It Works

Client: Initiates requests, renders UI, captures user input, displays results
Server: Receives requests, processes logic, accesses data, returns responses
Communication: Through network protocols (HTTP, WebSocket)
Separation: Client and server can be on different machines, even geographically separated
Responsibilities: Client focuses on presentation, server focuses on data/processing

This separation allows scaling—multiple clients can connect to one server, and servers can be scaled independently from clients.

Key Properties

Client makes requests, server provides responses
Client is typically front end, server is typically back end
Network communication between client and server
Server is usually more powerful, shared across clients
Client can be thin or thick (rich client with more logic)
Stateless or stateful communication patterns

Visual Explanation

Semantic Network

Connections

Built from:

Client — Requesting entity in the model
Server — Responding entity in the model

Builds into:

Front End — Client side is front end
Back End — Server side is back end
API — Communication interface between client and server

Related:

HTTP — Common protocol for client-server communication
Scalability — Benefit of client-server separation

Edge Cases & Gotchas

Network latency affects responsiveness
Server failure affects all connected clients
Requires well-designed APIs for communication
Security considerations for network communication

Client

2026-04-12T00:00:00.000Z

The Problem

How do users interact with networked services? What handles the user interface and initiates requests to servers?

Core Idea

A client is a computer or software that requests services from a server. In the client-server model, the client is typically the front end, handling user interaction and presentation.

How It Works

User Interface: Displays information and captures user input
Request Initiation: Sends requests to servers for data or services
Response Processing: Receives and processes server responses
Local Processing: May perform some computation locally
State Management: May maintain some client-side state

Clients can be web browsers, mobile apps, desktop applications, or any software that consumes server services.

Key Properties

Initiates requests to servers
Typically handles presentation and user interaction
Can be lightweight (thin client) or feature-rich (thick/rich client)
Runs on user devices, often less powerful than servers
May cache data for offline or performance reasons

Visual Explanation

Semantic Network

Connections

Builds into:

Front End — Client typically runs front end components

Related:

Client-Server Model — Client is one side of the model
Back End — Server counterpart to client

Edge Cases & Gotchas

Cannot securely store secrets (tokens, keys)
Limited by device capabilities
Network dependency affects functionality

Front End

2026-04-12T00:00:00.000Z

The Problem

Users need to interact with software applications, but the underlying data management and processing logic is too complex to expose directly. How do you present a user-friendly interface while keeping the underlying system intact?

Core Idea

Front end is the presentation layer of software that users interact with directly. It handles all user-facing tasks, providing an abstraction over the underlying components. In the client-server model, the front end typically resides on the client side.

How It Works

User Interface: Renders information and captures user input through UI elements
Input Handling: Processes user actions (clicks, gestures, keyboard input)
Communication: Sends requests to the back end via APIs and displays returned data
Rendering: Transforms data into visual representations (HTML, CSS, images)
Validation: Performs client-side validation before sending data to the server

In web development, front end includes HTML, CSS, JavaScript, frameworks (React, Angular, Vue.js), and handles responsive design, cross-browser compatibility, and web performance optimization.

Key Properties

User-facing and interactive
Handles presentation and UI logic
Client-side execution (in browser or device)
Abstracts underlying complexity from users
Includes markup (HTML), styling (CSS), and behavior (JavaScript)
Requires understanding of UI/UX design principles
Must handle multiple devices and screen sizes

Visual Explanation

Semantic Network

Connections

Built from:

Client — The front end typically runs on the client in client-server model
Server — Front end typically connects to servers for back end services
Presentation Layer — Front end implements the presentation layer concept
User Interface — Front end implements UI components

Builds into:

Full Stack — Front end combined with back end forms full stack
API — Front end consumes APIs to communicate with back end

Related:

Back End — Complements front end as the server-side counterpart
Single-Page Application — Modern front end architecture pattern

Edge Cases & Gotchas

Front end cannot securely store secrets; sensitive operations must go to back end
Client-side validation can be bypassed—always validate on back end
Browser differences require cross-browser testing and workarounds
Performance optimization critical ( Largest Contentful Paint, Time to Interactive )

Full Stack

2026-04-12T00:00:00.000Z

The Problem

Modern software development requires understanding both client-side and server-side technologies. How do developers work across the entire application stack?

Core Idea

Full stack refers to both the front end (presentation layer) and back end (data management/processing) together. A full stack developer has knowledge of the entire application from UI to database.

How It Works

Full stack developers understand:

Front End: HTML, CSS, JavaScript, frameworks (React, Angular, Vue.js)
Back End: Server languages (Node.js, Python, Java, PHP), APIs
Database: SQL, NoSQL, data modeling, queries
Version Control: Git and collaboration tools
DevOps: Deployment, CI/CD, infrastructure basics
Architecture: Understanding how components fit together

The developer can work on any part of the application, from user interface to database, bridging the gap between front end and back end.

Key Properties

Encompasses both front end and back end
Requires knowledge across multiple technology layers
Can build complete, functional applications independently
Understands data flow from UI to database and back
Uses version control tools (Git, Mercurial, Subversion)
Uses file transfer tools (FTP, rsync) for deployment

Visual Explanation

Semantic Network

Connections

Built from:

Front End — One half of full stack
Back End — The other half of full stack
Client-Server Model — Underlying architecture

Related:

API — Full stack developers work with APIs extensively
Version Control — Essential tool for full stack developers

Edge Cases & Gotchas

Full stack is a spectrum—nobody knows everything
Deep expertise in one area often more valuable than shallow knowledge everywhere
Technology constantly changes—continuous learning required

Server

2026-04-12T00:00:00.000Z

The Problem

How do you provide shared resources and services to multiple clients? What handles the data processing and storage that clients cannot or should not handle?, how do we assume that the client is not

Core Idea

A server is a computer or software that provides services to other computers (clients) over a network. In the client-server model, the server is typically the back end, managing data and logic.

How It Works

Listening: Server listens for client requests on specific ports
Request Handling: Receives, processes, and responds to client requests
Resource Management: Manages shared resources (databases, files, computation)
Authentication: Verifies client identity before granting access
Data Processing: Executes business logic and manipulates data
Response: Returns results to the client

Servers can be physical machines, virtual machines, or containers. They typically run continuously and are more powerful than client machines.

Key Properties

Provides services to multiple clients simultaneously
Usually runs remotely, physically separated from clients
Handles data storage, processing, and business logic
Can be scaled horizontally (more machines) or vertically (more resources)
High availability often requires redundancy

Visual Explanation

Semantic Network

Connections

Builds into:

Back End — Server typically runs back end components

Related:

Client-Server Model — Server is one side of the model
Front End — Client counterpart to server

Edge Cases & Gotchas

Server downtime affects all clients
Security critical—servers are attack targets
Performance bottlenecks can affect all users