Update over_the_wire.md

Author: oblomov-dev

docs/advanced/technical/over_the_wire.md

@@ -1,82 +1,89 @@
-# Over-the-Wire: An Introduction for Business Applications
+# Key Idea: Over-the-Wire in abap2UI5
 
-## Background: Why is this relevant again?
+## Introduction
 
-In the early days of web development, **all websites were server-rendered**.  
-Each user action, like clicking a link or submitting a form, triggered a full-page reload, with the server delivering the complete HTML response.
+The core idea of **abap2UI5** is to apply the principles of **Over-the-Wire (OtW)** web development to the SAP ecosystem.  
+Over-the-Wire refers to a pattern where the **server is responsible for rendering the user interface (UI)** and sends **ready-to-render HTML fragments** to the browser.  
+This avoids complex client-side frameworks and keeps the frontend lean and maintainable.
 
-With the rise of **Single Page Applications (SPAs)**, this changed. SPAs moved UI rendering and application logic to the browser, using JavaScript frameworks like React, Angular, or Vue. This allowed for rich, interactive user experiences—but also introduced significant complexity in development, deployment, and maintenance.
+While this approach is widely used in frameworks like Hotwire, Livewire, or Phoenix LiveView, **abap2UI5 adapts this idea for SAP**, using the SAPUI5 runtime to render the UI based on server-provided definitions.
 
-Today, **Over-the-Wire approaches revisit the original idea of server-side rendering**, but with modern techniques. Instead of sending entire pages, only small HTML fragments or UI updates are transferred, combining simplicity with interactivity.
+## Historical Context: From SSR to Over-the-Wire
 
-## What is "Over the Wire"?
+In the early days of web development, **Server-Side Rendering (SSR)** was the standard approach.  
+Every user interaction triggered a request to the server, which returned a fully rendered HTML page.
 
-**Over-the-Wire** refers to a development approach where the server generates and sends **ready-to-render HTML fragments** directly to the client (browser).  
-Unlike modern Single Page Applications (SPAs), which rely on JSON data and complex client-side rendering, Over-the-Wire keeps the frontend logic minimal and leverages server-side rendering for both initial load and dynamic updates.
+With the rise of **Single Page Applications (SPAs)**, UI rendering shifted to the browser.  
+SPAs request **raw data (e.g., JSON)** from the server and build the UI dynamically using JavaScript frameworks like React, Angular, or Vue.
 
-In simple terms:
-- The **server prepares the user interface** (UI) and sends it as HTML.
-- The **browser displays what the server sends**, without building the UI from raw data.
+While SPAs enable rich client-side experiences, they also introduce significant complexity:
+- API layers and data contracts
+- Separate frontend-backend development
+- Complex build & deployment pipelines
 
-This approach reduces complexity and is especially suitable for applications where business logic resides on the server.
+As a response to this complexity, the **Over-the-Wire approach re-emerged**:
+- The **server renders UI fragments**, not full pages.
+- The **browser simply inserts those fragments** into the page.
+- The frontend remains simple and declarative.
 
-## How does it differ from Single Page Applications (SPA)?
+Frameworks like **Hotwire (Rails)**, **Livewire (Laravel)**, and **Phoenix LiveView (Elixir)** are modern implementations of this concept.
 
-In a typical SPA:
-- The client requests **raw data** (e.g., JSON) from the server.
-- The frontend JavaScript framework processes the data and builds the UI dynamically in the browser.
+## Architectural Comparison
 
-In contrast, with Over-the-Wire:
-- The client requests **HTML fragments** directly from the server.
-- The server sends **fully rendered UI components**, which are inserted into the page.
+| Approach | Data Flow | Rendering Location |
+|----------|-----------|-------------------|
+| **SSR (classic)** | Full-page HTML responses | Entirely on the server |
+| **SPA** | Raw data (JSON), client builds UI | Client-side (JavaScript framework) |
+| **Over-the-Wire** | HTML fragments for partial updates | Server renders, browser inserts |
 
-This shifts the responsibility for UI rendering back to the server, simplifying the frontend layer.
+## Related Frameworks with Similar Ideas
 
-## Benefits of Over-the-Wire for Business Applications
-
-- **Reduced Frontend Complexity**: No need for heavy JavaScript frameworks or complex build pipelines.
-- **Faster Time-to-Market**: Leveraging existing backend logic accelerates development.
-- **Better SEO & Accessibility**: Server-rendered HTML is immediately visible and indexable.
-- **Lower Maintenance Effort**: Fewer dependencies and simpler architecture.
-- **Efficient for CRUD Applications**: Ideal for forms, tables, dashboards, and admin tools.
+| Framework | Key Use Case | Technology |
+|-----------|--------------|------------|
+| **[htmx](https://htmx.org/)** | Progressive enhancement for server-rendered apps | Any web stack |
+| **[Hotwire (Turbo)](https://hotwired.dev/)** | Modern Over-the-Wire for Rails apps | Ruby on Rails |
+| **[Phoenix LiveView](https://hexdocs.pm/phoenix_live_view)** | Real-time server-rendered UIs | Elixir / Phoenix |
+| **[Livewire](https://livewire.laravel.com/)** | Server-driven UI components | PHP / Laravel |
+| **[Unpoly](https://unpoly.com/)** | Simplifies partial page updates | Any web stack |
+| **[Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/)** | Server-side UI rendering with SignalR | .NET / C# |
+| **[Inertia.js](https://inertiajs.com/)** | SPA-like experience with server-driven UI | JavaScript + Laravel/Rails |
 
-## Limitations to Consider
+## Over-the-Wire in abap2UI5
 
-While Over-the-Wire offers significant advantages for backend-driven applications, it is less suitable for:
-- Highly interactive, real-time collaboration tools (e.g., design apps, chat platforms)
-- Applications requiring offline capabilities or rich client-side interactions
-- Scenarios where frontend and backend are developed by separate, independent teams
+**abap2UI5** adopts the Over-the-Wire principle but tailors it to SAP's technical environment:
 
-## Popular Frameworks and Tools Following Over-the-Wire Principles
+- The **ABAP backend defines the UI** via a **view and a view model**.
+- This structured data is sent to the browser.
+- The **SAPUI5 runtime (static frontend code)** renders the UI dynamically based on this data.
+- The frontend code itself is **never generated dynamically**. It remains stable and generic.
+- All business logic, UI definitions, and dynamic behavior are maintained on the backend.
 
-| Framework | Primary Use | Technology Stack |
-|-----------|-------------|-----------------|
-| **[htmx](https://htmx.org/)** | Enhances existing HTML pages with minimal JS | Technology-agnostic |
-| **[Hotwire (Turbo)](https://hotwired.dev/)** | Full Over-the-Wire framework for modern web apps | Ruby on Rails |
-| **[Phoenix LiveView](https://hexdocs.pm/phoenix_live_view)** | Real-time UI updates via WebSockets | Elixir / Phoenix |
-| **[Livewire](https://livewire.laravel.com/)** | Server-driven UI components for Laravel | PHP / Laravel |
-| **[Unpoly](https://unpoly.com/)** | Simplifies partial page updates without SPAs | Technology-agnostic |
-| **[Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/)** | Server-side UI rendering with SignalR | .NET / C# |
-| **[Inertia.js](https://inertiajs.com/)** | SPA-like experience without APIs | JavaScript + Laravel/Rails |
+### Key Characteristics:
+- **Frontend code is static** (SAPUI5 components).
+- **Backend fully controls UI definitions and logic**.
+- No separate frontend development needed.
+- Aligns with SAP's technology stack while following Over-the-Wire principles.
 
-## Over-the-Wire and abap2UI5
+## Benefits for SAP Applications
 
-The **abap2UI5** framework adopts the fundamental idea of Over-the-Wire, but with a specific focus on SAP development environments.  
-Instead of sending raw data to a generic frontend application, abap2UI5 delivers a **view and corresponding view model** from the ABAP backend to the client.
+- **Reduced Frontend Complexity**: No need for custom JavaScript development per app.
+- **Faster Development Cycles**: UI and logic are controlled via ABAP.
+- **Maintainable Architecture**: Reuse of SAPUI5 runtime, minimal frontend code.
+- **Seamless SAP Integration**: abap2UI5 fits into existing SAP systems.
+- **Ideal for Business Applications**: CRUD-heavy apps, forms, dashboards, transactions.
 
-Unlike traditional Over-the-Wire frameworks that send ready-made HTML fragments, abap2UI5 leverages the existing SAPUI5 runtime in the browser to render the final HTML dynamically.  
-However, this rendering is based on **static UI5 code**, which is **never changed or generated dynamically on the frontend**. All business logic, UI definitions, and dynamic behavior are controlled exclusively from the backend.
-
-In summary:
-- The **frontend code remains static and generic**.
-- The **backend defines what the UI should look like**, including the data and behavior.
-- This approach preserves the **Over-the-Wire principles of simplicity and backend-driven UI control**, while integrating seamlessly with SAPUI5 technology.
+## Limitations to Consider
 
-abap2UI5 thus bridges the gap between Over-the-Wire simplicity and the established SAPUI5 ecosystem, enabling efficient and maintainable web applications without introducing unnecessary frontend complexity.
+While Over-the-Wire (and abap2UI5) offers many advantages, it may not be suitable for:
+- Highly interactive, real-time collaboration tools (e.g., design apps, chat platforms).
+- Applications requiring offline capabilities.
+- Large-scale frontend projects developed independently from backend teams.
 
 ## Conclusion
 
-Over-the-Wire represents a pragmatic approach for building web applications where the **server remains in control of UI rendering**.  
-It aligns well with business contexts that prioritize **simplicity, maintainability, and tight integration of backend and frontend logic**.
+The **key idea of abap2UI5** is to apply the simplicity of the Over-the-Wire approach to the SAP world.  
+It enables building efficient, maintainable business applications by shifting UI control back to the backend, while using SAPUI5 as a stable frontend runtime.
+
+This reduces development complexity, shortens time-to-market, and ensures a clean architecture — without giving up the flexibility of SAPUI5.
 
-For typical business applications—such as dashboards, forms, and administrative tools—Over-the-Wire offers a lean and efficient alternative to heavy SPA architectures.
+For typical business applications — such as forms, tables, and dashboards — abap2UI5 offers a pragmatic alternative to traditional SPA architectures.