@volontariapp/messaging 1.0.0-snap-ae3e8c2 → 1.0.0-snap-bad6b22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +5 -1
- package/README.md +53 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
package/README.md
ADDED
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
# @volontariapp/messaging
|
|
2
|
+
|
|
3
|
+
Universal messaging contracts and architecture for Volontariapp.
|
|
4
|
+
|
|
5
|
+
## 🏗 LOB (Local Outbox) Architecture
|
|
6
|
+
|
|
7
|
+
The **LOB (Local Outbox)** pattern is used to ensure reliable message delivery between microservices while maintaining database consistency. It follows the **Change Data Capture (CDC)** approach.
|
|
8
|
+
|
|
9
|
+
### 🔄 Data Flow
|
|
10
|
+
|
|
11
|
+
1. **Database Change**: A transaction modifies data in a microservice's database (e.g., `ms-event`).
|
|
12
|
+
2. **SQL Trigger**: A native database trigger captures the change and inserts a record into the `event_queue` table.
|
|
13
|
+
3. **Outbox Table**: The `event_queue` (or `jobs_outbox`) table stores the event with its payload (`before`/`after`) and status (`PENDING`).
|
|
14
|
+
4. **Dispatcher**: A background worker polls the outbox table, sends the message to the broker (RabbitMQ/Kafka), and marks the record as `COMPLETED`.
|
|
15
|
+
|
|
16
|
+
### 📦 Package Structure
|
|
17
|
+
|
|
18
|
+
This package centralizes all message definitions to ensure type safety across the monorepo.
|
|
19
|
+
|
|
20
|
+
* **`events/`**: Definitions for domain events triggered by database changes.
|
|
21
|
+
* **`jobs/`**: Definitions for asynchronous jobs (e.g., sending emails).
|
|
22
|
+
* **`EventRegistry`**: A central TypeScript registry mapping event types to their respective payloads.
|
|
23
|
+
|
|
24
|
+
## 🛠 Usage
|
|
25
|
+
|
|
26
|
+
### Event Structure
|
|
27
|
+
|
|
28
|
+
All domain events follow a standard `EventChangedPayload` structure:
|
|
29
|
+
|
|
30
|
+
```typescript
|
|
31
|
+
export interface EventChangedPayload<T> {
|
|
32
|
+
before: T | null; // State before the change (null on INSERT)
|
|
33
|
+
after: T | null; // State after the change (null on DELETE)
|
|
34
|
+
}
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
### Type Safety
|
|
38
|
+
|
|
39
|
+
Use the `EventRegistry` to get strict typing when consuming events:
|
|
40
|
+
|
|
41
|
+
```typescript
|
|
42
|
+
import { EventMessagingType, type EventRegistry } from '@volontariapp/messaging';
|
|
43
|
+
|
|
44
|
+
type RequirementEvent = EventRegistry[EventMessagingType.REQUIREMENT_CHANGED];
|
|
45
|
+
// RequirementEvent now has the correct payload structure (before/after ITagPayload)
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## ➕ Adding a New Event
|
|
49
|
+
|
|
50
|
+
1. Define the payload interface in `src/events/[domain]/payloads.ts`.
|
|
51
|
+
2. Add the event type to the `EventMessagingType` enum.
|
|
52
|
+
3. Register the mapping in the `EventRegistry` interface in `src/events/index.ts`.
|
|
53
|
+
4. Implement the SQL trigger in the corresponding microservice to populate the outbox.
|