Merge pull request #17 from spinframework/chore/hub-content

chore(hub): bring over hub content

Author: vdice

content/api/hub/architecture_cqrs_go.md

@@ -0,0 +1,27 @@
+title = "CQRS With Go"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "go", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Go"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A Command and Query Responsibility Segregation (CQRS) implementation in Go"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/cqrs-go"
+keywords = "Architecture, HTTP, CQRS"
+
+---
+
+This is a simple Command and Query Responsibility Segregation (CQRS) implementation written in Go.
+
+### What Is Command and Query Responsibility Segregation (CQRS)
+
+CQRS is a software architectural pattern that separates the responsibility of handling commands (requests that change the system's state) from handling queries (requests that fetch data without modifying state). In a CQRS architecture, commands are handled by a separate component or layer known as the Command side, while queries are handled by another component or layer called the Query side. This segregation allows each side to be optimized independently, as they often have different scalability, performance, and optimization requirements.
+
+On the Command side, operations are focused on enforcing business rules, validation, and updating the state of the system. This side typically utilizes a domain-driven design approach to model the business logic effectively. On the Query side, the emphasis is on efficiently retrieving data to fulfill read requests from clients. This side often employs de-normalized data models and specialized data storage mechanisms optimized for fast read access. By separating the concerns of commands and queries, CQRS promotes a clearer separation of concerns and can lead to improved scalability, performance, and maintainability in complex software systems.

content/api/hub/architecture_cqrs_rust.md

@@ -0,0 +1,27 @@
+title = "CQRS With Rust"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "rust", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Rust"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A Command and Query Responsibility Segregation (CQRS) implementation in Rust"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/cqrs-rust"
+keywords = "Architecture, HTTP, CQRS"
+
+---
+
+This is a simple Command and Query Responsibility Segregation (CQRS) implementation written in Rust.
+
+### What Is Command and Query Responsibility Segregation (CQRS)
+
+CQRS is a software architectural pattern that separates the responsibility of handling commands (requests that change the system's state) from handling queries (requests that fetch data without modifying state). In a CQRS architecture, commands are handled by a separate component or layer known as the Command side, while queries are handled by another component or layer called the Query side. This segregation allows each side to be optimized independently, as they often have different scalability, performance, and optimization requirements.
+
+On the Command side, operations are focused on enforcing business rules, validation, and updating the state of the system. This side typically utilizes a domain-driven design approach to model the business logic effectively. On the Query side, the emphasis is on efficiently retrieving data to fulfill read requests from clients. This side often employs de-normalized data models and specialized data storage mechanisms optimized for fast read access. By separating the concerns of commands and queries, CQRS promotes a clearer separation of concerns and can lead to improved scalability, performance, and maintainability in complex software systems.

content/api/hub/architecture_crud_go_sqlite.md

@@ -0,0 +1,38 @@
+title = "CRUD APIs With Go and SQLite"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "Go", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Go"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A full-fledged CRUD API with SQLite backend written in Go"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/http-crud-go-sqlite"
+keywords = "Architecture, HTTP, CRUD"
+
+---
+
+This is a sample implementation of CRUD (Create, Read, Update, Delete) in Go. The sample is using SQLite for persistence and provides the following API endpoints via HTTP:
+
+- `GET /items` - To retrieve a list of all items
+- `GET /items/:id` - To retrieve a item using its identifier
+- `POST /items` - To create a new item
+- `PUT /items/:id` - To update an existing item using its identifier
+- `DELETE /items` - To delete multiple items providing an array of identifiers as payload (`{ "ids": []}`)
+- `DELETE /items/:id` - To delete an existing item using its identifier
+
+Send data to `POST /items` and `PUT /items/:id` using the following structure:
+
+```jsonc
+{
+    "name": "item name",
+    // boolean (either true or false)
+    "active": true
+}
+```

content/api/hub/architecture_crud_js_pg.md

@@ -0,0 +1,38 @@
+title = "CRUD APIs with JavaScript and PostgreSQL"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "JavaScript", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "JS/TS"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A full-fledged CRUD API with PostgreSQL backend written in JavaScript"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/http-crud-js-pg"
+keywords = "Architecture, HTTP, CRUD"
+
+---
+
+This is a sample implementation of CRUD (Create, Read, Update, Delete) in JavaScript. The sample is using PostgreSQL for persistence and provides the following API endpoints via HTTP:
+
+- `GET /items` - To retrieve a list of all items
+- `GET /items/:id` - To retrieve a item using its identifier
+- `POST /items` - To create a new item
+- `PUT /items/:id` - To update an existing item using its identifier
+- `DELETE /items` - To delete multiple items providing an array of identifiers as payload (`{ "ids": []}`)
+- `DELETE /items/:id` - To delete an existing item using its identifier
+
+Send data to `POST /items` and `PUT /items/:id` using the following structure:
+
+```jsonc
+{
+    "name": "item name",
+    // boolean (either true or false)
+    "active": true
+}
+```

content/api/hub/architecture_crud_js_sqlite.md

@@ -0,0 +1,38 @@
+title = "CRUD APIs with JavaScript and SQLite"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "JavaScript", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "JS/TS"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A full-fledged CRUD API with SQLite backend written in JavaScript"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/http-crud-js-sqlite"
+keywords = "Architecture, HTTP, CRUD"
+
+---
+
+This is a sample implementation of CRUD (Create, Read, Update, Delete) in JavaScript. The sample is using SQLite for persistence and provides the following API endpoints via HTTP:
+
+- `GET /items` - To retrieve a list of all items
+- `GET /items/:id` - To retrieve a item using its identifier
+- `POST /items` - To create a new item
+- `PUT /items/:id` - To update an existing item using its identifier
+- `DELETE /items` - To delete multiple items providing an array of identifiers as payload (`{ "ids": []}`)
+- `DELETE /items/:id` - To delete an existing item using its identifier
+
+Send data to `POST /items` and `PUT /items/:id` using the following structure:
+
+```jsonc
+{
+    "name": "item name",
+    // boolean (either true or false)
+    "active": true
+}
+```

content/api/hub/architecture_pub_sub.md

@@ -0,0 +1,26 @@
+title = "Polyglot Publish-Subscribe"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["publish-subscribe", "architecture", "polyglot"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Polyglot"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "Publish-Subscribe implementation using multiple programming languages (Rust, Go, JavaScript)"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/pub-sub-polyglot"
+keywords = "Architecture"
+
+---
+This sample contains a Publish-Subscribe (sometimes referred to as _pub/sub_) pattern implemented using different programming languages.
+
+### What is Publish-Subscribe
+
+The Publish-Subscribe pattern is a messaging pattern widely used in distributed systems to facilitate communication between multiple components or modules in a decoupled manner. In this pattern, publishers are responsible for producing messages containing data or events of interest, while subscribers express interest in specific types of messages by subscribing to relevant topics or channels. When a publisher generates a message, it is broadcasted to all subscribed subscribers without the publisher needing to have any knowledge of the subscribers' identities or how they process the messages. This decoupling enables loose coupling between components, making systems more flexible, scalable, and easier to maintain.
+
+Subscribers can react to messages they are interested in by executing predefined actions or processing the data contained within the messages. This pattern is commonly implemented using message brokers or event buses, where publishers send messages to a centralized location and subscribers receive messages from this central hub. By leveraging Publish-Subscribe, you can design systems where components are highly modular and can be easily extended or modified without affecting other parts of the system. Additionally, this pattern supports asynchronous communication, enabling efficient handling of large volumes of messages and improving system responsiveness.

content/api/hub/architecture_signed_webhooks.md

@@ -0,0 +1,27 @@
+title = "Signed Webhooks"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["webhooks", "rust", "python", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Rust"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "An implementation of signed webhooks using the WebAssembly Component Model."
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/signed-webhooks"
+keywords = "Architecture, HTTP, webhooks"
+
+---
+
+This sample demonstrates how to implement signed webhooks by extracting signing and verification logic into a dedicated WebAssembly Component and re-using it from within WebAssembly Components written in different programming languages.
+
+### What Are Signed Webhooks?
+
+Webhooks are automated messages sent from one application to another when a specific event occurs. They enable real-time communication and trigger actions in response to events, eliminating the need for continuous polling.
+
+Signing the payload of webhooks is crucial for ensuring the integrity and authenticity of the data being transmitted between applications. By signing the payload, you can verify that the data received from a webhook hasn't been tampered with during transit and originates from a trusted source. This security measure helps prevent various forms of attacks, such as data tampering or injection, which could potentially compromise the integrity and reliability of the system. 

content/api/hub/architecture_transparent_cache_rust.md

@@ -0,0 +1,25 @@
+title = "Transparent Cache with Rust"
+template = "render_hub_content_body"
+date = "2024-04-03T13:50:00Z"
+content-type = "text/plain"
+tags = ["http", "key-value", "rust", "architecture"]
+
+[extra]
+author = "Thorsten Hans"
+type = "hub_document"
+category = "Architecture"
+language = "Rust"
+created_at = "2024-04-03T13:50:00Z"
+last_updated = "2024-04-03T13:50:00Z"
+spin_version = ">=v2.4.0"
+summary = "A transparent cache implementation using key-value store"
+url = "https://github.com/fermyon/enterprise-architectures-and-patterns/tree/main/caching-rust"
+keywords = "Architecture, HTTP"
+
+---
+
+This example illustrates how to implement caching when building HTTP APIs.
+
+### What Is a Transparent Cache
+
+A transparent cache is a caching mechanism that operates without the explicit involvement or awareness of the end user or client application. In other words, users interacting with a system are unaware that caching is taking place behind the scenes. From the perspective of the user or client application, the caching process is invisible and does not impact the functionality or behavior of the system. Transparent caching is commonly employed in systems where performance optimization is crucial, such as web applications or content delivery networks (CDNs), to reduce latency and server load without affecting user experience.