@relaybus/core 0.0.0 → 0.2.0
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/README.md +230 -26
- package/dist/index.cjs +759 -63
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +608 -227
- package/dist/index.d.ts +608 -227
- package/dist/index.js +754 -64
- package/dist/index.js.map +1 -1
- package/package.json +20 -8
package/README.md
CHANGED
|
@@ -1,14 +1,55 @@
|
|
|
1
1
|
# @relaybus/core
|
|
2
2
|
|
|
3
|
+
@relaybus/core is the engine of relaybus, a reliable, storage-agnostic event bus for NestJS and Node.js: it writes events in the same database transaction as your data (the transactional outbox pattern) and delivers them to every handler with per-handler retries, leases, dead letters and ordering keys.
|
|
4
|
+
|
|
3
5
|
The relaybus engine: transactional publishing, per-handler deliveries, leased
|
|
4
6
|
dispatching, retries with jitter, dead letters, ordering keys and transport
|
|
5
|
-
routing.
|
|
7
|
+
routing. Most applications install it together with a store and, for NestJS,
|
|
8
|
+
the module:
|
|
6
9
|
|
|
7
10
|
```sh
|
|
8
|
-
pnpm add @relaybus/core
|
|
11
|
+
pnpm add @relaybus/core @relaybus/nestjs @relaybus/postgres pg
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
| Package | Use it for |
|
|
15
|
+
| ------------------------------------------------------------------------ | ------------------------------------------------------------- |
|
|
16
|
+
| [`@relaybus/nestjs`](https://www.npmjs.com/package/@relaybus/nestjs) | `RelayBusModule` and the `@Subscribe` decorator |
|
|
17
|
+
| [`@relaybus/postgres`](https://www.npmjs.com/package/@relaybus/postgres) | PostgreSQL store (pg, Prisma, TypeORM, Knex, Kysely, Drizzle) |
|
|
18
|
+
| [`@relaybus/mongodb`](https://www.npmjs.com/package/@relaybus/mongodb) | MongoDB store (driver or Mongoose sessions) |
|
|
19
|
+
| [`@relaybus/kafka`](https://www.npmjs.com/package/@relaybus/kafka) | Kafka transport between services |
|
|
20
|
+
| [`@relaybus/rabbitmq`](https://www.npmjs.com/package/@relaybus/rabbitmq) | RabbitMQ transport between services |
|
|
21
|
+
| [`@relaybus/testing`](https://www.npmjs.com/package/@relaybus/testing) | Contract suite, fake clock, in-memory transport |
|
|
22
|
+
|
|
23
|
+
## With NestJS
|
|
24
|
+
|
|
25
|
+
```ts
|
|
26
|
+
// order.events.ts
|
|
27
|
+
export class OrderPlaced extends defineEvent<{ orderId: string }>('order.placed.v1') {}
|
|
28
|
+
|
|
29
|
+
// app.module.ts
|
|
30
|
+
@Module({ imports: [RelayBusModule.forRoot({ store: new PostgresEventStore({ pool }) })] })
|
|
31
|
+
export class AppModule {}
|
|
32
|
+
|
|
33
|
+
// shipping.handlers.ts: consume with a decorator
|
|
34
|
+
@Injectable()
|
|
35
|
+
export class ShippingHandlers {
|
|
36
|
+
@Subscribe(OrderPlaced, { retry: { attempts: 5 } })
|
|
37
|
+
async ship(event: EventEnvelope<{ orderId: string }>) {
|
|
38
|
+
/* runs after the order transaction commits */
|
|
39
|
+
}
|
|
40
|
+
}
|
|
41
|
+
|
|
42
|
+
// order.service.ts: produce inside your transaction
|
|
43
|
+
await this.bus.transaction(async () => {
|
|
44
|
+
await this.orders.insert(order);
|
|
45
|
+
await this.bus.publish(new OrderPlaced({ orderId: order.id }), { key: order.id });
|
|
46
|
+
});
|
|
9
47
|
```
|
|
10
48
|
|
|
11
|
-
|
|
49
|
+
See the [project README](https://github.com/berkcansavur/relaybus#readme) for
|
|
50
|
+
guarantees and architecture.
|
|
51
|
+
|
|
52
|
+
## Without a framework
|
|
12
53
|
|
|
13
54
|
```ts
|
|
14
55
|
import { InMemoryEventStore, RelayBus, defineEvent } from '@relaybus/core';
|
|
@@ -37,32 +78,43 @@ Use a database store in production: [`@relaybus/postgres`](../postgres) or
|
|
|
37
78
|
|
|
38
79
|
## `new RelayBus(options)`
|
|
39
80
|
|
|
40
|
-
| Option | Default | Description
|
|
41
|
-
| ----------------------------------------- | --------------------------------------------- |
|
|
42
|
-
| `store` | required | `EventStore` implementation.
|
|
43
|
-
| `source` | `'relaybus'` | Service name recorded on every event.
|
|
44
|
-
| `transactionMode` | `'required'` | `'optional'` lets `publish` open its own transaction.
|
|
45
|
-
| `transactionResolver` | — | Returns the caller's active transaction, e.g. from `@nestjs-cls/transactional`.
|
|
46
|
-
| `unroutedEvents` | `'warn'` | `'throw'` rejects events without any handler or route.
|
|
47
|
-
| `retry` | 10 attempts, `1s`, ×2, max `10m`, full jitter | Default handler retry policy. `attempts: Infinity` retries forever.
|
|
48
|
-
| `handlerTimeout` | `false` | Default handler timeout.
|
|
49
|
-
| `dispatcher.enabled` | `true` | Run handlers in this process.
|
|
50
|
-
| `dispatcher.concurrency` | `10` | Handlers running at once.
|
|
51
|
-
| `dispatcher.batchSize` | concurrency | Deliveries claimed per query.
|
|
52
|
-
| `dispatcher.pollInterval` | `'1s'` | Idle wait between claims; retries are picked up on this cadence.
|
|
53
|
-
| `dispatcher.leaseDuration` | `'30s'` | Lease length, renewed every third while a handler runs.
|
|
54
|
-
| `dispatcher.shutdownTimeout` | `'30s'` | Wait for running handlers on `stop`, then release them.
|
|
55
|
-
| `
|
|
56
|
-
| `
|
|
57
|
-
| `retention.
|
|
58
|
-
| `
|
|
59
|
-
| `
|
|
60
|
-
| `
|
|
61
|
-
| `
|
|
62
|
-
| `
|
|
81
|
+
| Option | Default | Description |
|
|
82
|
+
| ----------------------------------------- | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
83
|
+
| `store` | required | `EventStore` implementation. |
|
|
84
|
+
| `source` | `'relaybus'` | Service name recorded on every event. |
|
|
85
|
+
| `transactionMode` | `'required'` | `'optional'` lets `publish` open its own transaction. |
|
|
86
|
+
| `transactionResolver` | — | Returns the caller's active transaction, e.g. from `@nestjs-cls/transactional`. |
|
|
87
|
+
| `unroutedEvents` | `'warn'` | `'throw'` rejects events without any handler or route. |
|
|
88
|
+
| `retry` | 10 attempts, `1s`, ×2, max `10m`, full jitter | Default handler retry policy. `attempts: Infinity` retries forever. |
|
|
89
|
+
| `handlerTimeout` | `false` | Default handler timeout. |
|
|
90
|
+
| `dispatcher.enabled` | `true` | Run handlers in this process. |
|
|
91
|
+
| `dispatcher.concurrency` | `10` | Handlers running at once. |
|
|
92
|
+
| `dispatcher.batchSize` | concurrency | Deliveries claimed per query. |
|
|
93
|
+
| `dispatcher.pollInterval` | `'1s'` | Idle wait between claims; retries are picked up on this cadence. |
|
|
94
|
+
| `dispatcher.leaseDuration` | `'30s'` | Lease length, renewed every third while a handler runs. |
|
|
95
|
+
| `dispatcher.shutdownTimeout` | `'30s'` | Wait for running handlers on `stop`, then release them. |
|
|
96
|
+
| `dispatcher.completionBatchWindow` | `'2ms'` | Deliveries that finish within this window are completed with one store call; `0` completes one by one. |
|
|
97
|
+
| `dispatcher.completionBatchSize` | `200` | Most deliveries completed in one store call. |
|
|
98
|
+
| `retention.completed` | `'7d'` | Delete events whose deliveries all completed after this; also the deduplication horizon. A completed delivery is deleted at once (see below). |
|
|
99
|
+
| `retention.dead` | `false` | Delete dead letters after this. |
|
|
100
|
+
| `retention.interval` | `'1h'` | Cleanup cadence. |
|
|
101
|
+
| `transports` / `routes` / `subscriptions` | — | Broker integration, see below. |
|
|
102
|
+
| `setupStore` | `true` | Create tables and indexes on `start`. |
|
|
103
|
+
| `observers` | `[]` | Lifecycle hooks for logs, metrics and tracing. |
|
|
104
|
+
| `logger` | `console` | `{ log, warn, error }`. |
|
|
105
|
+
| `clock`, `generateIdentifier`, `random` | system | Replace in tests. |
|
|
63
106
|
|
|
64
107
|
Durations are milliseconds or strings such as `'250ms'`, `'30s'`, `'5m'`, `'1h'`, `'7d'`.
|
|
65
108
|
|
|
109
|
+
**How the dispatcher schedules claims.** A claim that fills its batch is followed by the next one at once. Otherwise the
|
|
110
|
+
dispatcher sleeps until it is woken: by a publish, by the store reporting new deliveries from any process (the PostgreSQL
|
|
111
|
+
store through `LISTEN/NOTIFY`, the MongoDB store through a change stream), or by settled deliveries once 70% of a batch
|
|
112
|
+
(of `min(concurrency, batchSize)`) is free again, so slots are refilled in groups rather than one by one. A smaller number
|
|
113
|
+
of free slots is refilled after 10 ms without a claim, and the poll interval stays the safety net. Wake-ups within 5 ms
|
|
114
|
+
of a claim are merged into one claim. Settled unkeyed deliveries do not trigger a claim when their handler's last claim
|
|
115
|
+
got less than it asked for (nothing more was due); a settled keyed delivery always may, since it unblocks the next of
|
|
116
|
+
its key.
|
|
117
|
+
|
|
66
118
|
## Publishing
|
|
67
119
|
|
|
68
120
|
`publish(event, options)` and `publishAll(events, options)` write into, in
|
|
@@ -83,6 +135,123 @@ The handler receives the envelope and a context with `attempt`, `maxAttempts`,
|
|
|
83
135
|
- After a timeout or lease loss the handler's `signal` is aborted; the retry waits
|
|
84
136
|
for the abandoned run to settle so runs never overlap.
|
|
85
137
|
|
|
138
|
+
## Event catalogs
|
|
139
|
+
|
|
140
|
+
A catalog groups the events of one domain so the compiler checks that every event
|
|
141
|
+
has a handler and that only those events are published through it.
|
|
142
|
+
|
|
143
|
+
```ts
|
|
144
|
+
class OrderPlaced extends defineEvent<{ orderId: string }>('order.placed.v1') {}
|
|
145
|
+
class OrderShipped extends defineEvent<{ orderId: string; carrier: string }>('order.shipped.v1') {}
|
|
146
|
+
|
|
147
|
+
export const OrderEvents = defineCatalog({ OrderPlaced, OrderShipped }, { name: 'OrderEvents' });
|
|
148
|
+
|
|
149
|
+
// A class that misses a handler does not compile:
|
|
150
|
+
class ShippingHandlers implements HandlersOf<typeof OrderEvents> {
|
|
151
|
+
onOrderPlaced(event: EventOf<typeof OrderPlaced>, context: HandlerContext) {}
|
|
152
|
+
onOrderShipped(event: EventOf<typeof OrderShipped>) {}
|
|
153
|
+
}
|
|
154
|
+
bus.subscribeCatalog(OrderEvents, new ShippingHandlers()); // ids: OrderEvents.onOrderPlaced, ...
|
|
155
|
+
|
|
156
|
+
// Or declare the handlers as an object; missing or extra keys do not compile:
|
|
157
|
+
bus.subscribeCatalog(
|
|
158
|
+
OrderEvents,
|
|
159
|
+
defineHandlers(OrderEvents, {
|
|
160
|
+
onOrderPlaced: (event) => reserveStock(event.payload.orderId),
|
|
161
|
+
onOrderShipped: (event) => notify(event.payload.carrier),
|
|
162
|
+
}),
|
|
163
|
+
{ idPrefix: 'fulfilment' },
|
|
164
|
+
);
|
|
165
|
+
|
|
166
|
+
// Publish through a view that only accepts the catalog's events:
|
|
167
|
+
const orders = bus.forCatalog(OrderEvents);
|
|
168
|
+
await orders.publish(new OrderPlaced({ orderId }), { transaction });
|
|
169
|
+
await orders.publish(new UserRegistered({ userId })); // compile error
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
- `defineCatalog(events, { name? })` returns a frozen catalog with frozen entries. It rejects
|
|
173
|
+
empty catalogs, entries that are not event classes, names that are not identifiers of letters,
|
|
174
|
+
digits and underscores (a name becomes part of a method name and a handler id) and two entries
|
|
175
|
+
with one event type.
|
|
176
|
+
- `HandlersOf<C>` requires an `on${Key}` method per event; `HandlersOf<C, 'A' | 'B'>` requires
|
|
177
|
+
only those (`PartialHandlersOf<C, 'A' | 'B'>` is the same type), and `HandlersOf<C, K, Tx>` types
|
|
178
|
+
`context.transaction`. `EventOf<typeof OrderPlaced>` is the envelope type of one event;
|
|
179
|
+
`CatalogEvents<C, K?>` is the union of the catalog's (selected) events.
|
|
180
|
+
- `bus.subscribeCatalog(catalog, handlers, { events?, idPrefix?, ...subscribeOptions })` registers
|
|
181
|
+
the `on${Key}` method of every event (or of the `events` listed) with the stable id
|
|
182
|
+
`${idPrefix ?? catalog name ?? class name}.on${Key}` and `this` bound to `handlers`. Methods of
|
|
183
|
+
events that are not listed are ignored. A missing method does not compile and throws a
|
|
184
|
+
`ConfigurationError` naming it. Handlers are narrowed only by an `events` list the compiler can see;
|
|
185
|
+
options whose `events` may be absent require every handler.
|
|
186
|
+
- `defineHandlers(catalog, handlers, { events? })` checks completeness, extra keys (including
|
|
187
|
+
handlers of events that are not listed) and payload types at compile time and at runtime. A
|
|
188
|
+
handler may type its context, for example `HandlerContext<PoolClient>`.
|
|
189
|
+
- **Boot check:** `new RelayBus({ catalogs: [OrderEvents] })` (or `bus.registerCatalog`) makes
|
|
190
|
+
`start()` throw a `ConfigurationError` listing every catalog event that has no handler or route
|
|
191
|
+
and the method it expects. A failed check leaves the bus idle, before any I/O, so it can be fixed
|
|
192
|
+
and started again. For services that share a catalog, declare the role instead; see below.
|
|
193
|
+
- `forCatalog(...).publish` also checks the event type at runtime. TypeScript compares event
|
|
194
|
+
classes by shape, so two events with identical payload types are interchangeable to the compiler;
|
|
195
|
+
the runtime check still rejects the one that is not in the catalog, before anything is stored.
|
|
196
|
+
|
|
197
|
+
### Microservices: shared catalogs
|
|
198
|
+
|
|
199
|
+
In a system of services the catalog usually lives in a shared contracts package, and each service
|
|
200
|
+
produces some of its events and consumes others. Declare what this service does with each part:
|
|
201
|
+
|
|
202
|
+
```ts
|
|
203
|
+
import { consume, produce } from '@relaybus/core';
|
|
204
|
+
import { OrderEvents } from '@acme/contracts';
|
|
205
|
+
|
|
206
|
+
// orders service: publishes OrderPlaced to the broker, handles OrderShipped
|
|
207
|
+
class DeliveryStatusHandlers implements HandlersOf<typeof OrderEvents, 'OrderShipped'> {
|
|
208
|
+
onOrderShipped(event: EventOf<typeof OrderShipped>) {}
|
|
209
|
+
}
|
|
210
|
+
|
|
211
|
+
const bus = new RelayBus({
|
|
212
|
+
store,
|
|
213
|
+
transports: [kafka],
|
|
214
|
+
routes: [{ event: OrderPlaced, transport: 'kafka', destination: 'orders' }],
|
|
215
|
+
subscriptions: [{ transport: 'kafka', destinations: ['shipments'] }],
|
|
216
|
+
catalogs: [
|
|
217
|
+
produce(OrderEvents, { events: ['OrderPlaced'] }),
|
|
218
|
+
consume(OrderEvents, { events: ['OrderShipped'] }),
|
|
219
|
+
],
|
|
220
|
+
});
|
|
221
|
+
bus.subscribeCatalog(OrderEvents, new DeliveryStatusHandlers(), { events: ['OrderShipped'] });
|
|
222
|
+
const orders = bus.forCatalog(OrderEvents, { events: ['OrderPlaced'] });
|
|
223
|
+
await orders.publish(new OrderPlaced({ orderId }), { transaction, key: orderId });
|
|
224
|
+
await orders.publish(new OrderShipped({ orderId, carrier })); // compile error: not produced here
|
|
225
|
+
|
|
226
|
+
// shipping service: handles OrderPlaced only
|
|
227
|
+
class ShipmentHandlers implements HandlersOf<typeof OrderEvents, 'OrderPlaced'> {
|
|
228
|
+
onOrderPlaced(event: EventOf<typeof OrderPlaced>) {}
|
|
229
|
+
}
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
- `consume(catalog, { events? })`: each listed event (default: all) needs a **local handler**;
|
|
233
|
+
a route does not count. `produce(catalog, { events? })`: each listed event needs a **route to a
|
|
234
|
+
transport**, so nothing is published without a destination; a local handler does not count.
|
|
235
|
+
Both can be declared for one catalog, and for one event. Unknown names do not compile and are
|
|
236
|
+
rejected at runtime, as are empty and duplicate lists. A bare catalog keeps its meaning: every
|
|
237
|
+
event needs a handler or a route.
|
|
238
|
+
- `start()` lists every gap, per event:
|
|
239
|
+
|
|
240
|
+
```text
|
|
241
|
+
ConfigurationError: Catalog events this service does not cover:
|
|
242
|
+
- OrderEvents.OrderShipped (order.shipped.v1): consumed here, needs handler method onOrderShipped
|
|
243
|
+
- OrderEvents.OrderPlaced (order.placed.v1): produced here, needs a route to a transport
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
- `bus.forCatalog(catalog, { events })` publishes only the listed events: others do not compile
|
|
247
|
+
and are rejected at runtime before anything is stored.
|
|
248
|
+
- Received events (`bus.receive`, called by Kafka and RabbitMQ consumers) are matched to the
|
|
249
|
+
catalog handlers by event type, idempotently on the event id, and the payload is validated
|
|
250
|
+
against the event's schema before the handler runs; a payload that fails it is dead-lettered.
|
|
251
|
+
- Per-key order holds **per handler and event type**: events of one type and key reach a
|
|
252
|
+
handler in publish order (Kafka: same partition; RabbitMQ: `ordered: true`). Events of two
|
|
253
|
+
types under one key travel through separate routes and handlers and can interleave.
|
|
254
|
+
|
|
86
255
|
## Transports
|
|
87
256
|
|
|
88
257
|
```ts
|
|
@@ -104,12 +273,47 @@ transports acknowledge only after it resolves and dead-letter `InvalidEnvelopeEr
|
|
|
104
273
|
`listDeliveries(query)`, `requeue(ids)`, `statistics()`, `purgeExpired()`,
|
|
105
274
|
`handlers()`, `runOnce()` and `drain()` (tests), `start()` and `stop()`.
|
|
106
275
|
|
|
276
|
+
**Completed deliveries are deleted.** Completing a delivery removes its row instead
|
|
277
|
+
of updating it, which is what keeps the write cost of a delivery constant (see
|
|
278
|
+
`docs/performance/write-amplification.md`). `listDeliveries({ status: 'completed' })`
|
|
279
|
+
and `statistics().completed` therefore report nothing unless the store keeps a
|
|
280
|
+
completion history (`completionHistory: true` on the SQL stores,
|
|
281
|
+
`retainCompleted: true` on `InMemoryEventStore`). Deduplication does not depend
|
|
282
|
+
on it: an event remembers every handler it ever had a delivery for, so a
|
|
283
|
+
redelivered or republished event never runs a completed handler again, for as
|
|
284
|
+
long as the event is kept (`retention.completed`).
|
|
285
|
+
|
|
107
286
|
## Writing a store
|
|
108
287
|
|
|
109
288
|
Implement `EventStore` and run `eventStoreContract` from
|
|
110
289
|
[`@relaybus/testing`](../testing) against a real database. The contract defines
|
|
111
290
|
fencing, ordering, commit-order sequencing, visibility and purge semantics.
|
|
112
291
|
|
|
292
|
+
## When to use @relaybus/core, and when not to
|
|
293
|
+
|
|
294
|
+
Use it directly when you are not on NestJS, or when you write a custom `EventStore` or transport. Do not run it alone in production: add a store (`@relaybus/postgres` or `@relaybus/mongodb`). `InMemoryEventStore` refuses to start when `NODE_ENV=production`.
|
|
295
|
+
|
|
296
|
+
Documentation: <https://berkcansavur.github.io/relaybus/packages/core>
|
|
297
|
+
|
|
298
|
+
### relaybus vs alternatives
|
|
299
|
+
|
|
300
|
+
<!-- relaybus:snippet:comparison -->
|
|
301
|
+
|
|
302
|
+
| | What it is | Survives a restart | Written in your database transaction | Choose it when |
|
|
303
|
+
| -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
|
|
304
|
+
| **relaybus** | Event bus built on the transactional outbox: PostgreSQL and MongoDB stores, Kafka and RabbitMQ transports, per-handler deliveries | Yes, events live in your database | Yes | Events must never be lost or phantom, and handlers need retries, dead letters and ordering keys |
|
|
305
|
+
| [`@nestjs/event-emitter`](https://docs.nestjs.com/techniques/events) | In-process event emitter built on `eventemitter2` | No persistence is documented | No | Simple in-process notifications where losing an event on restart is acceptable |
|
|
306
|
+
| [`@nestjs/cqrs`](https://docs.nestjs.com/recipes/cqrs) | CommandBus, QueryBus, EventBus and sagas; the docs say sagas and event handlers run in memory | No built-in persistence | No | You want CQRS structure; it can sit on top of an outbox |
|
|
307
|
+
| [`@nestjs/outbox`](https://github.com/nestjs/outbox) | Transactional outbox module from the NestJS organisation: PostgreSQL, MySQL and in-memory stores, relay with leases and retries, dead-letter table, inbox | Yes with the database stores | Yes | You need MySQL, or a NestJS-organisation module; compare features with relaybus before choosing |
|
|
308
|
+
| [BullMQ](https://docs.bullmq.io/) | Job queue on Redis with retries, delayed jobs and flows; at-least-once in the worst case | Yes, in Redis | No, jobs are stored in Redis and cannot join a SQL or MongoDB transaction | Your stack is Redis-based and background jobs matter more than event atomicity |
|
|
309
|
+
| [pg-boss](https://github.com/timgit/pg-boss) | Job queue on PostgreSQL using `SKIP LOCKED`, with retries, dead letter queues, scheduling and pub/sub; jobs can be created in your own transaction | Yes, in PostgreSQL | Yes, through its database adapters | You want a PostgreSQL job queue with scheduling; relaybus is an event bus with per-handler deliveries and transports |
|
|
310
|
+
| Kafka client directly | A distributed log; the idempotent producer and transactions give exactly-once within Kafka | Yes, in Kafka | No, producing to Kafka is a second write | You consume and produce only inside Kafka; add an outbox when a database write must be announced |
|
|
311
|
+
|
|
312
|
+
This table summarises the vendors' own documentation as of October 2026; check their docs for current details.
|
|
313
|
+
Full comparison and sources: <https://berkcansavur.github.io/relaybus/comparison>.
|
|
314
|
+
|
|
315
|
+
<!-- relaybus:end -->
|
|
316
|
+
|
|
113
317
|
## License
|
|
114
318
|
|
|
115
319
|
MIT
|