- Part 1: The Database: SQLite - Part 2: The No-ORM ORM - A very simple Data Abstraction Layer. - Part 3: Developing a Web Server Application in Go. - Part 4: Datastar - a lightweight framework for real-time collaborative web apps. - Part 5: Modern HTML and modern CSS. - Part 6: Web components. - Part 7: Simple Deployments with a VPS, Nginx, Certbot and a single binary file. --- class: default transition: fade-out --- # Part 1: SQLite: ### It is fast, feature complete* and rock solid.

## It is not SQ-Lite, it is SQL-ite Since everybody knows SQLite, today just a few highlights: - It has JSON and JSONB as built-in data types. - It has 29 new functions to extract from JSON or to create JSON objects. - It's CTEs make SQL Turing complete. - The SQLite CLI can be used to execute "SQL-scripts". See demo. \* It lacks features essential for a client-server environment, primarily multi-user concurrent write access, built-in security and user management, and some advanced data types.

* from my pov and for my needs and purposes

--- class: default transition: fade-out --- # Part 2: A very simple Data Abstraction Layer:

Features: - Simplified Database Lifecycle Management. - A 'Record' Data Type for Generic Data Handling. - High-Level CRUD Operations. - Fluent Transaction API. - Abstraction and Safety. - Utility Functions.

--- class: default transition: fade-out --- # Part 3: Developing a Web Server Application in Go.

Why Go? - Go is a compiled language that generates native machine code. - Go's core strength is its built-in, lightweight concurrency model using goroutines and channels. - Go has a small, well-defined specification and a deliberately simple syntax. - The standard library is comprehensive, especially for web development. - Go compiles into a single, static binary with no external dependencies. - Go is simple, just 25 reserved words in the language. - Can embed the database engine (modernc/sqlite) - Can serve static code from embeded folders and files. - Can embed other resources, like sql files or template files. - Has a built-in templating engine. --- layout: quote transition: fade-out --- # Part 4: Datastar ## Build reactive web apps that stand the test of time Datastar is a lightweight framework for building everything from simple sites to real-time collaborative web apps.

Quote Gillian Delany: > The problem is Datastar is actually a backend agnostic backend framework with a 10 Kb shim. There has never been anything like it in practice. So it is hard to explain. --- class: default --- --- class: default --- # Reducing the Network to a Function Call ```js { const { data, error } = await to(fetch("https://api.example.com/api/board")); if (error) { // handle error return; } // handle data } { const { data, error } = await to(fetch("https://api.example.com/api/users/12")); if (error) { // handle error return; } // handle data } // the function that "unwraps" the promise: export function to(promise: Promise) { return promise .then((response) => response.json()) .then((data) => ({ data, error: null })) .catch((error) => ({ data: null, error })); } ``` --- class: default --- # HTTP - Protocol #

POST https://api.example.com/api/users/search?page=2&limit=10 HTTP/1.1

Host: api.example.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

Accept: application/json

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Cookie: sessionId=abc123; theme=dark

Content-Length: 89

{

body: data for the search request

}

--- class: default --- # SSE - Server-Sent Events #

GET https://api.example.com/api/events/stream HTTP/1.1

Host: api.example.com

Accept: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

Response:

HTTP/1.1 200 OK

Content-Type: text/event-stream

Cache-Control: no-cache

Connection: keep-alive

event: message

data: {"user": "Alice", "action": "joined"}

event: update

data: {"count": 42}

data: Multi-line

data: message example

--- layout: two-cols layoutClass: gap-16 --- # HTTP Communication # ```mermaid { scale: 0.6} sequenceDiagram participant Browser participant Backend Note over Browser,Backend: Traditional HTTP (Polling) Browser->>Backend: GET /api/data Backend-->>Browser: Response with data Note over Browser: Wait... Browser->>Backend: GET /api/data Backend-->>Browser: Response with data Note over Browser: Wait... Browser->>Backend: GET /api/data Backend-->>Browser: Response with data ``` ::right:: # SSE Communication # ```mermaid { scale: 0.6} sequenceDiagram participant Browser participant Backend Note over Browser,Backend: Server-Sent Events (SSE) Browser->>Backend: GET /api/events (Accept: text/event-stream) Backend-->>Browser: 200 OK (Connection open) Note over Backend,Browser: Connection stays open Backend-->>Browser: event: updatedata: {...} Backend-->>Browser: event: updatedata: {...} Backend-->>Browser: event: updatedata: {...} Note over Browser,Backend: Real-time updates without new requests ``` --- layout: default transition: fade-out --- # Hypermedia - The Representation is the Data: The representation (e.g., the HTML document) delivered from the server to the client contains all the data needed for that specific application state. - Presentation and Links are Embedded: Crucially, not only is the raw data embedded, but also the presentation instructions (via CSS or HTML structure) and, most importantly for the workflow, the hypermedia controls (links and forms) that define the next possible state transitions. - Hypermedia as the Engine of Application State (HATEOAS): This is the central feature of the workflow. The representations sent from the server must include hyperlinks and/or forms that indicate the valid next state transitions (the available actions) the client can take. The client does not use pre-compiled knowledge of the workflow; it is driven by the links provided in the current document. --- layout: two-cols layoutClass: gap-2 --- ```mermaid { scale: 0.4} graph TD Start([Client Starts]) --> GetProducts[GET /products] GetProducts --> ProductResp["Response: Product List
links:
add-to-cart: /cart/items
self: /products"] ProductResp --> AddCart[POST /cart/items] AddCart --> CartResp["Response: Cart Updated
links:
self: /cart
update-item: /cart/items/id
remove-item: /cart/items/id
checkout: /checkout"] CartResp --> Decision1{Client Action} Decision1 -->|Continue Shopping| GetProducts Decision1 -->|Proceed| Checkout[POST /checkout] Checkout --> CheckoutResp["Response: Checkout Session
links:
payment: /payment
cancel: /cart"] ``` ::right:: ```mermaid { scale: 0.4} graph TD CheckoutResp["Response: Checkout Session
links:
payment: /payment
cancel: /cart"] --> Payment[POST /payment] Payment --> PaymentResp["Response: Payment Success
links:
order: /orders/id
track: /orders/id/tracking
invoice: /orders/id/invoice"] PaymentResp --> GetOrder[GET /orders/id] GetOrder --> OrderState{Order State} OrderState -->|Pending| PendingResp["Response: Order Pending
links:
self: /orders/id
cancel: /orders/id/cancel
track: /orders/id/tracking"] OrderState -->|Shipped| ShippedResp["Response: Order Shipped
links:
self: /orders/id
track: /orders/id/tracking
return: /orders/id/return"] OrderState -->|Delivered| DeliveredResp["Response: Order Delivered
links:
self: /orders/id
return: /orders/id/return
review: /orders/id/review"] PendingResp --> End([Workflow Complete]) ShippedResp --> End DeliveredResp --> End ``` --- class: default --- # Learn Some Templating System:

| Concept | Example | Meaning | | ----------------- | ---------------------------------------- | -------------------------- | | **Interpolation** | `{{ name }}` | Insert value of `name` | | **Loop** | `{% for item in items %}...{% endfor %}` | Repeat block for each item | | **Condition** | `{% if logged_in %}Welcome{% endif %}` | Conditional rendering | | **Include** | `{% include 'header.html' %}` | Reuse a subtemplate | | **Escaping** | `{{{ raw_html }}}` or `{{& raw_html}}` | Control HTML escaping | --- class: default --- # Templating and Hypermedia:

| | Templating | Hypermedia as the Engine of Application State | | --------- | ------------------------ | ------------------------------------------ | | Input | Data | Data + available transitions | | Output | Document (HTML) | Document representing a state with actions | | Function | Bind data to structure | Bind state transitions to structure | | Goal | Present information | Drive navigation and state evolution | | Mechanism | Placeholder substitution | Link/form embedding | | Example | `{{.Title}}` → “Article” | `Edit` | --- class: default --- # Putting Everything Together ##

At the core, the backend holds the application state — typically in a database. All decisions about data, relationships, and transitions originate here.

The backend generates pages by combining data (state), presentation, and transitions (actions) using a templating engine. This approach follows HATEOAS, a hypermedia-driven design where each page contains links and instructions describing valid next steps.

The backend can also actively drive the frontend using Server-Sent Events (SSE). SSE allows updates to be pushed to the client in real-time, keeping the application synchronized without full page reloads.

On the frontend, Datastar enables fine-grained interactivity and incremental page updates. Instead of replacing entire pages like simple hypermedia, Datastar updates only the elements affected by the state changes, keeping the interface responsive and dynamic.

--- class: default clicks: 7 --- # The Name "Datastar" ## Comes from the custom data-* Attribute

A custom data- attribute is an HTML attribute that allows you to store extra information about an HTML element in a standard, private way. It must be named starting with the prefix data-, for example: data-product-id="123".

<div id="foo" data-what-ever= "Any String you want" > Lorem ... </div>

there even is a javascript api for this: ```js const el = document.getElementById("foo"); el.dataset.whatEver = "you've got it!"; ```

- Every HTML element provides a key–value store (via its .dataset property) for arbitrary data you want to associate with that element. - data-* attributes are real, queryable, and stylable DOM attributes. You can select them in CSS, query them in JS, and even animate style changes as their values change. --- class: default clicks: 5 --- # Datastar and `data-*` Attributes ##

The Datastar library builds on a simple, native web standard: custom data-* attributes. Each element can carry its own key–value store of information, making HTML itself the natural host for behavior and state.

Datastar defines 21 data-* attributes that express intent directly in markup. These attributes describe data flow, user interactions, and state transitions without writing imperative JavaScript.

The values of those attributes form a small, declarative DSL — called Datastar Expressions. Each expression describes what should happen when data or events change, turning attributes into a layer of reactive logic.

By keeping logic inside the elements, Datastar achieves locality of behavior — where markup, data, and interactivity remain close together. This makes components easier to read, reason about, and maintain.

Datastar provides a set of built-in actions (helper functions) that can be used in Datastar expressions to interact with the backend. The main actions are: @get(), @post(), @put(), @patch(), and @delete().

```html ``` --- layout: image image: /mariner.png transition: slide-up level: 2 --- # to be continued ... --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart LR %% Publishers Scheduler["⏰ Scheduler
(periodic tasks)"] API["🌐 REST API
(user actions)"] Worker["⚙️ Background Job
(processing tasks)"] %% EventBus EventBus["🧭 EventBus"] %% Subscribers SSE["📡 SSE Broadcaster
(push to clients)"] Logger["📝 Audit Logger
(write to SQLite)"] Cache["🗃 Cache Updater"] Notifier["🔔 Notification Service"] %% Client UI Client["💻 Clients
via SSE"] %% Flows Scheduler -->|publishes: task.tick| EventBus API -->|publishes: ticket.created| EventBus Worker -->|publishes: task.completed| EventBus EventBus -->|subscribes: task.*| SSE EventBus -->|subscribes: ticket.*| SSE EventBus -->|subscribes: *| Logger EventBus -->|subscribes: cache.invalidate| Cache EventBus -->|subscribes: notify.*| Notifier SSE -->|SSE stream| Client ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart LR subgraph Publishers Scheduler["⏰ Scheduler
(periodic tasks)"] API["🌐 API
(user triggers)"] Worker["⚙️ Background Job"] end EventBus["🧭 EventBus
(pub/sub hub)"] subgraph Subscribers SSE["📡 SSE Broadcaster"] Logger["📝 Audit Logger"] Notifier["🔔 Notification Service"] Cache["🗃 Cache Updater"] end Client["💻 Clients via SSE"] Scheduler --> EventBus API --> EventBus Worker --> EventBus EventBus --> SSE EventBus --> Logger EventBus --> Notifier EventBus --> Cache SSE --> Client ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} sequenceDiagram participant P as Publisher (Scheduler) participant EB as EventBus participant S1 as SSE Broadcaster participant S2 as Audit Logger participant UI as Client UI P->>EB: Publish("task.tick", data) EB->>S1: Dispatch event EB->>S2: Dispatch event S1->>UI: Push via SSE S2->>S2: Write to SQLite ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} classDiagram class EventBus { - mu sync.RWMutex - subscribers map[string][]EventChannel - stats *Stats + Publish(topic, data) + PublishAsync(topic, data) + Subscribe(topic) EventChannel + SubscribeCallback(topic, cb) } class EventChannel { <> chan Event } class Event { Data map[string]interface Topic string wg *sync.WaitGroup + Done() } class Stats { - data map[string]TopicStats + GetPublishedCountByTopic(t) int + GetSubscriberCountByTopic(t) int } EventBus --> EventChannel : delivers Events EventBus --> Stats Event --> Stats : increments counters ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart TD Publish["Publish()"] Mutex["RWMutex Lock"] Channels["subscribers[topic]"] GoRoutine["Goroutine for dispatch"] Sub1["Subscriber #1"] Sub2["Subscriber #2"] Publish --> Mutex Mutex --> Channels Channels --> GoRoutine GoRoutine --> Sub1 GoRoutine --> Sub2 ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart TB subgraph Backend EB["EventBus"] DB["SQLite Database"] Scheduler API Worker SSE["SSE Broadcaster"] Logger end subgraph Clients Browser["Browser UI"] end Scheduler --> EB API --> EB Worker --> EB EB --> SSE EB --> Logger Logger --> DB SSE --> Browser ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart LR Client["🌐 Browser\n(HTML + JS)"] subgraph Server["🖥 Go Application Server"] EB["EventBus"] SSE["SSE Handler"] API["HTTP API"] Worker["Background Worker"] Scheduler["Cron Scheduler"] DB["SQLite File"] end Client <--> SSE Client <--> API Scheduler --> Worker Worker --> EB API --> EB EB --> SSE EB --> DB ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart TD A["1️⃣ Publisher creates event"] B["2️⃣ EventBus receives event"] C["3️⃣ Match subscribers (wildcard + exact)"] D["4️⃣ Dispatch to channels"] E["5️⃣ Subscribers handle event"] F["6️⃣ Optional: push to client via SSE"] G["7️⃣ Stats updated"] A --> B --> C --> D --> E --> F --> G ``` --- class: default --- # Eventbus Architecture

```mermaid { scale: 0.68} flowchart LR Topic["Incoming Topic: ticket.updated"] Exact["Exact Match: ticket.updated"] Wild1["Wildcard: ticket.*"] Wild2["Wildcard: *"] Result["Matched Subscribers"] Topic --> Exact Topic --> Wild1 Topic --> Wild2 Exact --> Result Wild1 --> Result Wild2 --> Result ```

Drake Formular

The "Drake" Formular of Webtechnologies

The Space of Webtechnologies

A holistic developer