113 lines
2.2 KiB
Markdown
113 lines
2.2 KiB
Markdown
|
# 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.
|