1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
//! Topic router — spec section 22.3.
//!
//! This module defines the [`TopicRouter`] trait and its primary
//! implementation [`LocalRouter`]. A router is responsible for
//! resolving a topic name into a [`Route`] that contains the
//! [`TopicEntry`] handle for that topic.
//!
//! # Design motivation
//!
//! In a single-process deployment, the router is a thin lookup layer:
//! every topic lives in the local [`TopicStore`], and resolution is a
//! simple `get_or_create` call. The trait abstraction exists so that a
//! future distributed deployment can plug in a hash-based or
//! affinity-based router (e.g. consistent hashing across broker
//! shards) without changing any call-sites in the broker or server
//! layers.
//!
//! # Auto-creation
//!
//! The [`LocalRouter`] creates topics on demand when they are first
//! referenced. The new topic is initialized with the default profile
//! provided at router construction time via the
//! `default_profile_factory` closure. This lazy creation pattern
//! means producers and consumers do not need to pre-register topics.
use Arc;
use crateTopicEntry;
use crateTopicStore;
/// A routing decision produced by a [`TopicRouter`].
///
/// Contains the [`TopicEntry`] handle that the broker should use for
/// all topic-level operations (publish permission checks, subscriber
/// counts, profile lookups, etc.).
/// Trait for resolving topic names to routing decisions.
///
/// Implementations must be both [`Send`] and [`Sync`] so they can be
/// shared across async tasks. The `route` method is called for every
/// publish and subscribe operation, so implementations should aim for
/// low latency.
///
/// # Arguments for `route`
///
/// * `topic` — The topic name to resolve.
/// * `routing_key` — An optional routing key for future use (e.g.
/// partition key for hash-based routing). Currently unused by the
/// [`LocalRouter`] implementation.
/// Single-process topic router that resolves topics via the local
/// [`TopicStore`].
///
/// When `route` is called, the router looks up the topic in the store
/// and creates it on demand if it does not yet exist. New topics are
/// initialized with the default profile produced by the
/// `default_profile_factory` closure provided at construction time.
///
/// # Examples
///
/// ```ignore
/// use std::sync::Arc;
/// use rifts::broker::router::LocalRouter;
/// use rifts::topic::{TopicStore, TopicProfile};
///
/// let store = TopicStore::new();
/// let router = LocalRouter::new(store, Arc::new(TopicProfile::default));
/// let route = router.route("orders", None).unwrap();
/// assert_eq!(route.entry.name, "orders");
/// ```