Skip to content

Commit 8d0bd30

Browse files
oblomov-devoblomov-dev
authored
Update over_the_wire.md
1 parent aa9d276 commit 8d0bd30

File tree

1 file changed

+62
-59
lines changed

1 file changed

+62
-59
lines changed

‎docs/advanced/technical/over_the_wire.md‎

Lines changed: 62 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -1,97 +1,100 @@
11
# Over-the-Wire in SAP: The Key Idea of abap2UI5
22

3-
The key idea of **abap2UI5** is to apply the principles of **Over-the-Wire** web development to the SAP ecosystem.
3+
The core principle of **abap2UI5** is to apply the proven **Over-the-Wire** concept to SAP UI5 application development.
44

5-
Over-the-Wire refers to a pattern where the server is responsible for rendering the user interface and sends ready-to-render HTML fragments to the browser. This avoids complex client-side frameworks and keeps the frontend lean and maintainable.
5+
**Over-the-Wire** refers to a web architecture where the server renders user interfaces and sends ready-to-use HTML fragments to the browser. This avoids complex client-side frameworks and keeps the frontend lightweight and maintainable.
66

7-
While this approach is widely used in frameworks like Hotwire, Livewire, or Phoenix LiveView, **abap2UI5 adapts this idea for the SAP technoligal environment**, using the SAP UI5 framework to render the UI based on server-provided definitions created in ABAP.
7+
While popular frameworks like Hotwire, Livewire, and Phoenix LiveView follow this approach, **abap2UI5 adapts it to SAP’s technological environment**, using SAP UI5 for frontend rendering and ABAP for backend-driven UI definitions.
88

9+
## Concept Overview
10+
11+
```plaintext
912
+------------------------+ +-----------------------+ +--------------------+
1013
| ABAP Backend | | Browser | | User |
1114
|------------------------| |-----------------------| |--------------------|
12-
| - XML View Definition | --> | Receives JSON View | --> | Interacts with UI |
15+
| - XML View Definition | --> | Receives Response | --> | Interacts with UI |
1316
| - JSON View-Model | | Renders with UI5 | | (clicks, inputs) |
1417
+------------------------+ +-----------------------+ +--------------------+
18+
```
19+
Flow:
20+
- The backend defines UI5 XML Views and JSON View-Models
21+
- The browser renders these definitions using a static UI5 application
22+
- Users interact with the UI — the backend handles logic and updates
1523

24+
## From SSR to Over-the-Wire: A Brief History
1625

17-
### History: From SSR to Over-the-Wire
18-
19-
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.
26+
In early web development, **Server-Side Rendering (SSR)** was the default. Every user action triggered a full-page reload with a complete HTML response.
2027

21-
With the rise of Single Page Applications (SPAs), UI rendering shifted to the browser. SPAs request raw data (e.g., JSON) from the server typically send via OData and build the UI dynamically using JavaScript frameworks like React, Angular, or Vue at the frontend.
28+
The rise of **Single Page Applications (SPAs)** shifted rendering to the browser. SPAs fetch raw data (often via OData in SAP) and dynamically build UIs with JavaScript frameworks like React, Angular, or Vue.
2229

23-
While SPAs enable rich client-side experiences, they also introduce significant complexity:
30+
However, SPAs brought new challenges:
2431
- API layers and data contracts
25-
- Separate frontend-backend development
32+
- Separate frontend-backend development workflows
2633
- Complex build & deployment pipelines
2734

28-
As a response to this complexity, the Over-the-Wire approach re-emerged:
29-
- The server renders UI fragments, not full pages
30-
- The browser simply inserts those fragments into the page
31-
- The frontend remains simple and declarative
35+
As a reaction, the **Over-the-Wire** paradigm re-emerged:
36+
- Servers send UI fragments, not full pages.
37+
- Browsers update only specific parts of the page.
38+
- Frontends stay simple and declarative.
3239

33-
##### Architectural Comparison
40+
### Architectural Comparison
3441

35-
| Approach | Data Flow | Rendering Location | Time |
36-
|----------|-----------|-------------------|-------------|
42+
| Approach | Data Flow | Rendering Location | Period |
43+
|----------|-----------|-------------------|--------|
3744
| **SSR** | Full-page HTML responses | Entirely on the server | 1990s – 2010s |
38-
| **SPA** | Raw data (JSON), client builds UI | Client-side (JavaScript framework) | 2010s – today |
45+
| **SPA** | Raw data (JSON), client builds UI | Client-side (JavaScript) | 2010s – today |
3946
| **Over-the-Wire** | HTML fragments for partial updates | Server renders, browser inserts | 2020s (re-emerging) |
4047

41-
##### Over-the-Wire Frameworks
48+
## Over-the-Wire Frameworks
4249

43-
The followring frameworks are implementations of this concept.
50+
Several frameworks successfully implement this pattern:
4451

4552
| Framework | Key Use Case | Technology |
4653
|-----------|--------------|------------|
47-
| **[htmx](https://htmx.org/)** | Progressive enhancement for server-rendered apps | Any web stack |
48-
| **[Hotwire (Turbo)](https://hotwired.dev/)** | Modern Over-the-Wire for Rails apps | Ruby on Rails |
49-
| **[Phoenix LiveView](https://hexdocs.pm/phoenix_live_view)** | Real-time server-rendered UIs | Elixir / Phoenix |
50-
| **[Livewire](https://livewire.laravel.com/)** | Server-driven UI components | PHP / Laravel |
51-
| **[Unpoly](https://unpoly.com/)** | Simplifies partial page updates | Any web stack |
52-
| **[Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/)** | Server-side UI rendering with SignalR | .NET / C# |
53-
| **[Inertia.js](https://inertiajs.com/)** | SPA-like experience with server-driven UI | JavaScript + Laravel/Rails |
54-
55-
### Over-the-Wire in abap2UI5
54+
| [htmx](https://htmx.org/) | Progressive enhancement for server-rendered apps | Any web stack |
55+
| [Hotwire (Turbo)](https://hotwired.dev/) | Modern Over-the-Wire for Rails apps | Ruby on Rails |
56+
| [Phoenix LiveView](https://hexdocs.pm/phoenix_live_view) | Real-time server-rendered UIs | Elixir / Phoenix |
57+
| [Livewire](https://livewire.laravel.com/) | Server-driven UI components | PHP / Laravel |
58+
| [Unpoly](https://unpoly.com/) | Simplified partial page updates | Any web stack |
59+
| [Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/) | Server-side UI rendering with SignalR | .NET / C# |
60+
| [Inertia.js](https://inertiajs.com/) | SPA-like experience with server-driven UI | JavaScript + Laravel/Rails |
5661

57-
**abap2UI5** adopts the Over-the-Wire principle but tailors it to SAP's technical environment:
62+
## abap2UI5: Over-the-Wire for SAP
5863

59-
- The ABAP backend defines the UI via a UI5 XML View and UI5 JSON View-Model
60-
- This data is sent to the browser
61-
- A static UI5 frontend app renders the UI dynamically based on this responses
62-
- The frontend code itself is never generated dynamically. It remains stable and generic.
63-
- All business logic, UI definitions, and dynamic behavior are maintained on the backend in an ABAP Class
64+
**abap2UI5** transfers the Over-the-Wire idea into SAP’s world by combining:
65+
- ABAP-based UI definitions (XML Views & JSON View-Models)
66+
- A static SAP UI5 frontend app for rendering
67+
- Backend-controlled UI logic and state management
6468

65-
##### Key Characteristics:
66-
- Frontend code is a static UI5 app and send with the first request
67-
- Backend fully controls UI definitions and logic
68-
- No separate frontend development needed, all apps are pure backend abap artifacts
69-
- Aligns with SAP's technology stack (ABAP & UI5) while following Over-the-Wire principles
69+
### Key Characteristics
70+
- Static UI5 frontend delivered once.
71+
- Backend defines and controls UI structure and behavior.
72+
- Pure ABAP development — no custom JavaScript needed.
73+
- Seamless alignment with SAP's UI5 and ABAP technology stack.
7074

71-
##### Benefits for SAP Applications
75+
### Benefits for SAP Applications
7276

73-
- **Reduced Frontend Complexity**: No need for custom JavaScript development
74-
- **Faster Development Cycles**: UI and logic are controlled via ABAP in the backend
75-
- **Maintainable Architecture**: No frontend code, all apps are ABAP Classes
76-
- **Seamless SAP Integration**: abap2UI5 app run on any ERP and S/4 release
77-
- **Ideal for Business Applications**: CRUD-heavy apps, forms, dashboards, transactions etc.
77+
- **Simplified Frontend**: No custom JavaScript, no separate frontend development.
78+
- **Faster Development Cycles**: All logic and UI changes are managed in ABAP.
79+
- **Maintainable Architecture**: UI definitions reside in ABAP Classes — no frontend builds required.
80+
- **Full SAP Integration**: Runs on any ERP or S/4HANA release, compatible with standard SAP infrastructure.
81+
- **Perfect for Business Apps**: Ideal for CRUD-heavy applications, forms, tables, and dashboards.
7882

79-
##### Limitations to Consider
83+
### Limitations to Consider
8084

81-
While Over-the-Wire (and abap2UI5) offers many advantages, it may not be suitable for:
82-
* Highly interactive, real-time collaboration tools (e.g., design apps, chat platforms)
83-
* Applications requiring offline capabilities or rich client-side interactions
84-
* Scenarios where frontend and backend are developed by separate, independent teams
85+
- Not suitable for highly interactive, real-time collaboration apps.
86+
- Offline functionality or complex client-side interactions are not covered.
87+
- Less effective if frontend and backend teams work independently.
8588

86-
### Conclusion
89+
## Conclusion
8790

88-
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 SAP UI5 as a frontend framework.
91+
The **key idea of abap2UI5** is to bring the simplicity and efficiency of the Over-the-Wire pattern into the SAP ecosystem.
8992

90-
This reduces development complexity, shortens time-to-market, and ensures a clean architecture — without giving up the flexibility of SAPUI5.
93+
By shifting UI control back to the ABAP backend and leveraging SAP UI5 for rendering, abap2UI5 enables maintainable, pragmatic business applications — without the overhead of SPA architectures.
9194

92-
For typical business applications — such as forms, tables, and dashboards — abap2UI5 offers a pragmatic alternative to traditional SPA architectures.
95+
For typical enterprise apps — forms, dashboards, transactions — abap2UI5 offers a clean, backend-driven alternative with faster time-to-market and lower complexity.
9396

94-
### Further Reading
95-
* [Fiori-like web app development in pure ABAP with htmx and Fundamental](https://community.sap.com/t5/technology-blog-posts-by-members/fiori-like-web-app-development-in-pure-abap-with-htmx-and-fundamental/ba-p/13500763)
96-
* [htmx in a nutshell](https://htmx.org/docs/#introduction)
97-
* [html-over-the-wire](https://signalvnoise.com/svn3/html-over-the-wire/)
97+
## Further Reading
98+
- [Fiori-like web app development in pure ABAP with htmx and Fundamental](https://community.sap.com/t5/technology-blog-posts-by-members/fiori-like-web-app-development-in-pure-abap-with-htmx-and-fundamental/ba-p/13500763)
99+
- [htmx in a nutshell](https://htmx.org/docs/#introduction)
100+
- [HTML Over the Wire – Basecamp’s approach](https://signalvnoise.com/svn3/html-over-the-wire/)

0 commit comments

Comments
 (0)