coulomb/frontend-patterns
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
frontend-patterns/sequences/GeneralWebApplication.md
tegwick 2a5dabdc85 Preserve initial frontend pattern language research scaffold 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-24 07:55:34 +02:00

2.2 KiB
Raw Permalink Blame History

General Web Application — Generative Sequence

Status: hypothesis

Starting question

How should a web application progressively resolve its frontend architecture without starting from a framework choice?

Sequence

1. Characterize the experience

Identify:

  • dominant user activities,
  • interaction intensity,
  • continuity requirements,
  • collaboration requirements,
  • offline requirements,
  • addressability requirements,
  • latency sensitivity.

2. Place authority

Choose among patterns such as:

  • Server Authority
  • Local Authority
  • Replicated Authority
  • Event-Log Authority

3. Establish addressability

Determine what must be named, linked, revisited, bookmarked or shared.

Potential patterns:

  • URL as Application State
  • Resource Address
  • Hierarchical Route

4. Place projection

Determine where perceivable state is derived.

Potential patterns:

  • Static Projection
  • Server Projection
  • Client Projection
  • Hybrid Projection
  • Streaming Projection

5. Choose the communication window

Determine whether communication is:

  • request/response,
  • polling,
  • long-lived,
  • streamed,
  • replicated,
  • peer-to-peer.

6. Add local affordances

Identify state that should remain near the user interaction.

Potential patterns:

  • Local Interaction State
  • Pending State
  • Immediate Feedback
  • Optimistic Overlay

7. Define mutation and reconciliation

Decide:

  • command shape,
  • idempotency,
  • conflict handling,
  • invalidation,
  • resynchronization.

8. Establish feature boundaries

Determine which domain and interaction capabilities can evolve independently.

9. Establish deployment boundaries

Only split independent deployment where the organizational and runtime forces justify it.

10. Strengthen quality boundaries

Apply accessibility, failure containment, security, privacy, observability and performance patterns.

11. Measure and adapt

Observe runtime behavior and revisit earlier choices when actual forces differ from assumed forces.

Research status

This sequence must be tested against contrasting architectures:

  • content site,
  • CRUD SaaS,
  • real-time dashboard,
  • collaborative editor,
  • e-commerce storefront,
  • local-first application,
  • microfrontend estate.