aspyx-service 0.10.0__tar.gz → 0.10.2__tar.gz
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.
Potentially problematic release.
This version of aspyx-service might be problematic. Click here for more details.
- aspyx_service-0.10.2/PKG-INFO +517 -0
- aspyx_service-0.10.2/README.md +481 -0
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/pyproject.toml +2 -2
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/channels.py +93 -32
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/registries.py +31 -30
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/restchannel.py +90 -30
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/serialization.py +61 -61
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/server.py +5 -8
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/service.py +23 -6
- aspyx_service-0.10.2/tests/__init__.py +1 -0
- aspyx_service-0.10.2/tests/common.py +300 -0
- aspyx_service-0.10.2/tests/config.yaml +13 -0
- aspyx_service-0.10.2/tests/test_async_service.py +58 -0
- aspyx_service-0.10.2/tests/test_service.py +82 -0
- aspyx_service-0.10.0/PKG-INFO +0 -37
- aspyx_service-0.10.0/README.md +0 -1
- aspyx_service-0.10.0/tests/config.yaml +0 -4
- aspyx_service-0.10.0/tests/test-service.py +0 -423
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/.gitignore +0 -0
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/LICENSE +0 -0
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/__init__.py +0 -0
- {aspyx_service-0.10.0 → aspyx_service-0.10.2}/src/aspyx_service/healthcheck.py +0 -0
|
@@ -0,0 +1,517 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: aspyx_service
|
|
3
|
+
Version: 0.10.2
|
|
4
|
+
Summary: Aspyx Service framework
|
|
5
|
+
Author-email: Andreas Ernst <andreas.ernst7@gmail.com>
|
|
6
|
+
License: MIT License
|
|
7
|
+
|
|
8
|
+
Copyright (c) 2025 Andreas Ernst
|
|
9
|
+
|
|
10
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
11
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
12
|
+
in the Software without restriction, including without limitation the rights
|
|
13
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
14
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
15
|
+
furnished to do so, subject to the following conditions:
|
|
16
|
+
|
|
17
|
+
The above copyright notice and this permission notice shall be included in all
|
|
18
|
+
copies or substantial portions of the Software.
|
|
19
|
+
|
|
20
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
21
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
22
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
23
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
24
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
25
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
26
|
+
SOFTWARE.
|
|
27
|
+
License-File: LICENSE
|
|
28
|
+
Requires-Python: >=3.9
|
|
29
|
+
Requires-Dist: aspyx>=1.5.1
|
|
30
|
+
Requires-Dist: fastapi~=0.115.13
|
|
31
|
+
Requires-Dist: httpx~=0.28.1
|
|
32
|
+
Requires-Dist: msgpack~=1.1.1
|
|
33
|
+
Requires-Dist: python-consul2~=0.1.5
|
|
34
|
+
Requires-Dist: uvicorn[standard]
|
|
35
|
+
Description-Content-Type: text/markdown
|
|
36
|
+
|
|
37
|
+
# aspyx
|
|
38
|
+
|
|
39
|
+

|
|
40
|
+

|
|
41
|
+

|
|
42
|
+

|
|
43
|
+

|
|
44
|
+
[](https://pypi.org/project/aspyx/)
|
|
45
|
+
[](https://coolsamson7.github.io/aspyx/index/introduction)
|
|
46
|
+
|
|
47
|
+

|
|
48
|
+
|
|
49
|
+
# Service
|
|
50
|
+
|
|
51
|
+
- [Introduction](#introduction)
|
|
52
|
+
- [Features](#features)
|
|
53
|
+
- [Service and Component declaration](#service-and-component-declaration)
|
|
54
|
+
- [Service and Component implementation](#service-and-component-implementation)
|
|
55
|
+
- [Health Checks](#health-checks)
|
|
56
|
+
- [Service Manager](#service-manager)
|
|
57
|
+
- [Component Registry](#component-registry)
|
|
58
|
+
- [Channels](#channels)
|
|
59
|
+
- [Performance](#performance)
|
|
60
|
+
- [Rest Calls](#rest-calls)
|
|
61
|
+
- [Intercepting calls](#intercepting-calls)
|
|
62
|
+
- [FastAPI server](#fastapi-server)
|
|
63
|
+
- [Implementing Channels](#implementing-channels)
|
|
64
|
+
- [Version History](#version-history)
|
|
65
|
+
|
|
66
|
+
## Introduction
|
|
67
|
+
|
|
68
|
+
The Aspyx service library is built on top of the DI core framework and adds a microservice based architecture,
|
|
69
|
+
that lets you deploy, discover and call services with different remoting protocols and pluggable discovery services.
|
|
70
|
+
|
|
71
|
+
The basic design consists of four different concepts:
|
|
72
|
+
|
|
73
|
+
!!! info "Service"
|
|
74
|
+
defines a group of methods that can be called either locally or remotely.
|
|
75
|
+
These methods represent the functional interface exposed to clients — similar to an interface in traditional programming
|
|
76
|
+
|
|
77
|
+
!!! info "Component"
|
|
78
|
+
a component bundles one or more services and declares the channels (protocols) used to expose them.
|
|
79
|
+
Think of a component as a deployment unit or module.
|
|
80
|
+
|
|
81
|
+
!!! info "Component Registry "
|
|
82
|
+
acts as the central directory for managing available components.
|
|
83
|
+
It allows the framework to register, discover, and resolve components and their services.
|
|
84
|
+
|
|
85
|
+
!!! info "Channel"
|
|
86
|
+
is a pluggable transport layer that defines how service method invocations are transmitted and handled.
|
|
87
|
+
|
|
88
|
+
Let's look at the "interface" layer first.
|
|
89
|
+
|
|
90
|
+
**Example**:
|
|
91
|
+
```python
|
|
92
|
+
@service(name="test-service", description="test service")
|
|
93
|
+
class TestService(Service):
|
|
94
|
+
@abstractmethod
|
|
95
|
+
def hello(self, message: str) -> str:
|
|
96
|
+
pass
|
|
97
|
+
|
|
98
|
+
@component(name="test-component", services =[TestService])
|
|
99
|
+
class TestComponent(Component):
|
|
100
|
+
pass
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
After booting the DI infrastructure with a main module we could already call a service:
|
|
104
|
+
|
|
105
|
+
**Example**:
|
|
106
|
+
```python
|
|
107
|
+
@module(imports=[ServiceModule])
|
|
108
|
+
class Module:
|
|
109
|
+
def __init__(self):
|
|
110
|
+
pass
|
|
111
|
+
|
|
112
|
+
@create()
|
|
113
|
+
def create_registry(self) -> ConsulComponentRegistry:
|
|
114
|
+
return ConsulComponentRegistry(Server.port, "http://localhost:8500") # a consul based registry!
|
|
115
|
+
|
|
116
|
+
environment = Environment(Module)
|
|
117
|
+
service_manager = environment.get(ServiceManager)
|
|
118
|
+
|
|
119
|
+
service = service_manager.get_service(TestService)
|
|
120
|
+
|
|
121
|
+
service.hello("world")
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
The technical details are completely transparent, as a dynamic proxy encapsulates the internals.
|
|
125
|
+
|
|
126
|
+
As we can also host implementations, lets look at this side as well:
|
|
127
|
+
|
|
128
|
+
```python
|
|
129
|
+
@implementation()
|
|
130
|
+
class TestComponentImpl(AbstractComponent, TestComponent):
|
|
131
|
+
# constructor
|
|
132
|
+
|
|
133
|
+
def __init__(self):
|
|
134
|
+
super().__init__()
|
|
135
|
+
|
|
136
|
+
# implement Component
|
|
137
|
+
|
|
138
|
+
def get_addresses(self, port: int) -> list[ChannelAddress]:
|
|
139
|
+
return [ChannelAddress("dispatch-json", f"http://{Server.get_local_ip()}:{port}")]
|
|
140
|
+
|
|
141
|
+
@implementation()
|
|
142
|
+
class TestServiceImpl(TestService):
|
|
143
|
+
def __init__(self):
|
|
144
|
+
pass
|
|
145
|
+
|
|
146
|
+
def hello(self, message: str) -> str:
|
|
147
|
+
return f"hello {message}"
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
The interesting part if the `get_addresses` method that return a list of channel addresses, that can be used to execute remote calls.
|
|
151
|
+
In this case a channel is used that exposes a single http endpoint, that will dispatch to the correct service method.
|
|
152
|
+
This information is registered with the appropriate component registry and is used by other processes.
|
|
153
|
+
|
|
154
|
+
The required - `FastAPI` - infrastructure to expose those services is started with the call:
|
|
155
|
+
|
|
156
|
+
```python
|
|
157
|
+
server = FastAPIServer(host="0.0.0.0", port=8000)
|
|
158
|
+
|
|
159
|
+
environment = server.boot(Module)
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
Of course, service can also be called locally. In case of multiple possible channels, a keyword argument is used to
|
|
163
|
+
determine a specific channel. As a local channel has the name "local", the appropriate call is:
|
|
164
|
+
|
|
165
|
+
```python
|
|
166
|
+
service = service_manager.get_service(TestService, preferred_channel="local")
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
## Features
|
|
170
|
+
|
|
171
|
+
The library offers:
|
|
172
|
+
|
|
173
|
+
- sync and async support
|
|
174
|
+
- multiple - extensible - channel implementations supporting dataclasses and pydantic data models.
|
|
175
|
+
- ability to customize http calls with interceptors ( via the AOP abilities )
|
|
176
|
+
- `fastapi` based channels covering simple rest endpoints including `msgpack` support.
|
|
177
|
+
- `httpx` based clients for dispatching channels and simple rest endpoint with the help of low-level decorators.
|
|
178
|
+
- first registry implementation based on `consul`
|
|
179
|
+
- support for configurable health checks
|
|
180
|
+
|
|
181
|
+
As well as the DI and AOP core, all mechanisms are heavily optimized.
|
|
182
|
+
A simple benchmark resulted in message roundtrips in significanlty under a ms per call.
|
|
183
|
+
|
|
184
|
+
Let's see some details
|
|
185
|
+
|
|
186
|
+
## Service and Component declaration
|
|
187
|
+
|
|
188
|
+
Every service needs to inherit from the "tagging interface" `Service`
|
|
189
|
+
|
|
190
|
+
```python
|
|
191
|
+
@service(name="test-service", description="test service")
|
|
192
|
+
class TestService(Service):
|
|
193
|
+
@abstractmethod
|
|
194
|
+
def hello(self, message: str) -> str:
|
|
195
|
+
pass
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
The decorator can add a name and a description. If `name` is not set, the class name converted to snake case is used.
|
|
199
|
+
|
|
200
|
+
A component needs to derive from `Component`:
|
|
201
|
+
|
|
202
|
+
```python
|
|
203
|
+
@component(services =[TestService])
|
|
204
|
+
class TestComponent(Component):
|
|
205
|
+
pass
|
|
206
|
+
```
|
|
207
|
+
|
|
208
|
+
The `services` argument references a list of service interfaces that are managed by this component, meaning that they all are
|
|
209
|
+
exposed by the same channels.
|
|
210
|
+
|
|
211
|
+
`Component` defines the abstract methods:
|
|
212
|
+
|
|
213
|
+
- `def startup(self) -> None`
|
|
214
|
+
called initially after booting the system
|
|
215
|
+
|
|
216
|
+
- `def shutdown(self) -> None:`
|
|
217
|
+
called before shutting fown the system
|
|
218
|
+
|
|
219
|
+
- `def get_addresses(self, port: int) -> list[ChannelAddress]:`
|
|
220
|
+
return a list of available `ChannelAddress`es that this component exposes
|
|
221
|
+
|
|
222
|
+
- `def get_status(self) -> ComponentStatus:`
|
|
223
|
+
return the status of this component ( one of the `ComponentStatus` enums `VIRGIN`, `RUNNING`, and `STOPPED`)
|
|
224
|
+
|
|
225
|
+
- `async def get_health(self) -> HealthCheckManager.Health:`
|
|
226
|
+
return the health status of a component implementation.
|
|
227
|
+
|
|
228
|
+
## Service and Component implementation
|
|
229
|
+
|
|
230
|
+
Service implementations implement the corresponding interface and are decorated with `@implementation`
|
|
231
|
+
|
|
232
|
+
```python
|
|
233
|
+
@implementation()
|
|
234
|
+
class TestServiceImpl(TestService):
|
|
235
|
+
def __init__(self):
|
|
236
|
+
pass
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
The constructor is required since the instances are managed by the DI framework.
|
|
240
|
+
|
|
241
|
+
Component implementations derive from the interface and the abstract base class `AbstractComponent`
|
|
242
|
+
|
|
243
|
+
```python
|
|
244
|
+
@implementation()
|
|
245
|
+
class TestComponentImpl(AbstractComponent, TestComponent):
|
|
246
|
+
# constructor
|
|
247
|
+
|
|
248
|
+
def __init__(self):
|
|
249
|
+
super().__init__()
|
|
250
|
+
|
|
251
|
+
# implement Component
|
|
252
|
+
|
|
253
|
+
def get_addresses(self, port: int) -> list[ChannelAddress]:
|
|
254
|
+
return [ChannelAddress("dispatch-json", f"http://{Server.get_local_ip()}:{port}")]
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
As a minimum you have to declare the constructor and the `get_addresses` method, that exposes channel addresses
|
|
258
|
+
|
|
259
|
+
## Health Checks
|
|
260
|
+
|
|
261
|
+
Every component can declare a HTTP health endpoint and the corresponding logic to compute the current status.
|
|
262
|
+
|
|
263
|
+
Two additional things have to be done:
|
|
264
|
+
|
|
265
|
+
- adding a `@health(<endpoint>)` decorator to the class
|
|
266
|
+
- implementing the `get_health()` method that returns a `HealthCheckManager.Health`
|
|
267
|
+
|
|
268
|
+
While you can instantiate the `Health` class directly via
|
|
269
|
+
|
|
270
|
+
```
|
|
271
|
+
HealthCheckManager.Health(HealtStatus.OK)
|
|
272
|
+
```
|
|
273
|
+
|
|
274
|
+
it typically makes more sense to let the system execute a number of configured checks and compute the overall result automatically.
|
|
275
|
+
|
|
276
|
+
For this purpose injectable classes can be decorated with `@health_checks()` that contain methods in turn decorated with `@health_check`
|
|
277
|
+
|
|
278
|
+
**Example**:
|
|
279
|
+
|
|
280
|
+
```python
|
|
281
|
+
@health_checks()
|
|
282
|
+
@injectable()
|
|
283
|
+
class Checks:
|
|
284
|
+
def __init__(self):
|
|
285
|
+
pass
|
|
286
|
+
|
|
287
|
+
@health_check(fail_if_slower_than=1)
|
|
288
|
+
def check_performance(self, result: HealthCheckManager.Result):
|
|
289
|
+
... # should be done in under a second
|
|
290
|
+
|
|
291
|
+
@health_check(name="check", cache=10)
|
|
292
|
+
def check(self, result: HealthCheckManager.Result):
|
|
293
|
+
ok = ...
|
|
294
|
+
result.set_status(if ok HealthStatus.OK else HealthStatus.ERROR)
|
|
295
|
+
```
|
|
296
|
+
|
|
297
|
+
The methods are expected to have a single parameter of type `HealthCheckManager.Result` that can be used to set the status including detail information with
|
|
298
|
+
|
|
299
|
+
```
|
|
300
|
+
set_status(status: HealthStatus, details = "")
|
|
301
|
+
```
|
|
302
|
+
|
|
303
|
+
When called, the default is already `OK`.
|
|
304
|
+
|
|
305
|
+
The decorator accepts a couple of parameters:
|
|
306
|
+
|
|
307
|
+
- `fail_if_slower_than=0`
|
|
308
|
+
time in `s` that the check is expected to take as a maximum. As soon as the time is exceeded, the status is set to `ERROR`
|
|
309
|
+
- `cache`
|
|
310
|
+
time in 's' that the last result is cached. This is done in order to prevent health-checks putting even more strain on a heavily used system.
|
|
311
|
+
|
|
312
|
+
## Service Manager
|
|
313
|
+
|
|
314
|
+
`ServiceManager` is the central class used to retrieve service proxies.
|
|
315
|
+
|
|
316
|
+
```python
|
|
317
|
+
def get_service(self, service_type: Type[T], preferred_channel="") -> T
|
|
318
|
+
```
|
|
319
|
+
|
|
320
|
+
- `type` is the requested service interface
|
|
321
|
+
- `preferred_channel` the name of the preferred channel.
|
|
322
|
+
|
|
323
|
+
If not specified, the first registered channel is used, which btw. is a local channel - called `local` - in case of implementing services.
|
|
324
|
+
|
|
325
|
+
## Component Registry
|
|
326
|
+
|
|
327
|
+
The component registry is the place where component implementations are registered and retrieved.
|
|
328
|
+
|
|
329
|
+
In addition to a `LocalComponentRegistry` ( which is used for testing purposes ) the only implementation is
|
|
330
|
+
|
|
331
|
+
`ConsulComponentRegistry`
|
|
332
|
+
|
|
333
|
+
Constructor arguments are
|
|
334
|
+
|
|
335
|
+
- `port: int` the own port
|
|
336
|
+
- `consul: Consul` the consul instance
|
|
337
|
+
|
|
338
|
+
The component registry is also responsible to execute regular health-checks to track component healths.
|
|
339
|
+
As soon as - in our case consul - decides that a component is not alive anymore, it will notify the clients via regular heartbeats about address changes
|
|
340
|
+
which will be propagated to channels talking to the appropriate component.
|
|
341
|
+
|
|
342
|
+
Currently, this only affects the list of possible URLs which are required by the channels!
|
|
343
|
+
|
|
344
|
+
## Channels
|
|
345
|
+
|
|
346
|
+
Channels implement the possible transport layer protocols. In the sense of a dynamic proxy, they are the invocation handlers!
|
|
347
|
+
|
|
348
|
+
Several channels are implemented:
|
|
349
|
+
|
|
350
|
+
- `dispatch-json`
|
|
351
|
+
channel that dispatches generic `Request` objects via a `invoke` POST-call
|
|
352
|
+
- `dispatch-msgpack`
|
|
353
|
+
channel that dispatches generic `Request` objects via a `invoke` POST-call after packing the json with msgpack
|
|
354
|
+
- `rest`
|
|
355
|
+
channel that executes regular rest-calls as defined by a couple of decorators.
|
|
356
|
+
|
|
357
|
+
All channels react on changed URLs as provided by the component registry.
|
|
358
|
+
|
|
359
|
+
A so called `URLSelector` is used internally to provide URLs for every single call. Two subclasses exist that offer a different logic
|
|
360
|
+
|
|
361
|
+
- `FirstURLSelector` always returns the first URL of the list of possible URLs
|
|
362
|
+
- `RoundRobinURLSelector` switches sequentially between all URLs.
|
|
363
|
+
|
|
364
|
+
To customize the behavior, an around advice can be implemented easily:
|
|
365
|
+
|
|
366
|
+
**Example**:
|
|
367
|
+
|
|
368
|
+
```python
|
|
369
|
+
@advice
|
|
370
|
+
class ChannelAdvice:
|
|
371
|
+
def __init__(self):
|
|
372
|
+
pass
|
|
373
|
+
|
|
374
|
+
@advice
|
|
375
|
+
class ChannelAdvice:
|
|
376
|
+
def __init__(self):
|
|
377
|
+
pass
|
|
378
|
+
|
|
379
|
+
@around(methods().named("customize").of_type(Channel))
|
|
380
|
+
def customize_channel(self, invocation: Invocation):
|
|
381
|
+
channel = cast(Channel, invocation.args[0])
|
|
382
|
+
|
|
383
|
+
channel.select_round_robin() # or select_first_url()
|
|
384
|
+
|
|
385
|
+
return invocation.proceed()
|
|
386
|
+
```
|
|
387
|
+
|
|
388
|
+
### Performance
|
|
389
|
+
|
|
390
|
+
I benchmarked the different implementations with a recursive dataclass as an argument and return value.
|
|
391
|
+
The avg response times - on a local server - where all below 1ms per call.
|
|
392
|
+
|
|
393
|
+
- rest calls are the slowest ( about 0.7ms )
|
|
394
|
+
- dispatching-json 20% faster
|
|
395
|
+
- dispatching-msgpack 30% faster
|
|
396
|
+
|
|
397
|
+
The biggest advantage of the dispatching flavors is, that you don't have to worry about the additional decorators!
|
|
398
|
+
|
|
399
|
+
### Rest Calls
|
|
400
|
+
|
|
401
|
+
Invoking rest calls requires decorators and some marker annotations.
|
|
402
|
+
|
|
403
|
+
**Example**:
|
|
404
|
+
|
|
405
|
+
```python
|
|
406
|
+
@service()
|
|
407
|
+
@rest("/api")
|
|
408
|
+
class TestService(Service):
|
|
409
|
+
@get("/hello/{message}")
|
|
410
|
+
def hello(self, message: str) -> str:
|
|
411
|
+
pass
|
|
412
|
+
|
|
413
|
+
@post("/post/")
|
|
414
|
+
def set_data(self, data: Body(Data)) -> Data:
|
|
415
|
+
pass
|
|
416
|
+
```
|
|
417
|
+
|
|
418
|
+
The decorators `get`, `put`, `post` and `delete` specify the methods.
|
|
419
|
+
|
|
420
|
+
If the class is decorated with `@rest(<prefix>)`, the corresponding prefix will be appended at the beginning.
|
|
421
|
+
|
|
422
|
+
Additional annotations are
|
|
423
|
+
- `Body` the post body
|
|
424
|
+
- `QueryParam`marked for query params
|
|
425
|
+
|
|
426
|
+
### Intercepting calls
|
|
427
|
+
|
|
428
|
+
The client side HTTP calling is done with `httpx` instances of type `Httpx.Client` or `Httpx.AsyncClient`.
|
|
429
|
+
|
|
430
|
+
To add the possibility to add interceptors - for token handling, etc. - the channel base class `HTTPXChannel` defines
|
|
431
|
+
the methods `make_client()` and `make_async_client` that can be modified with an around advice.
|
|
432
|
+
|
|
433
|
+
**Example**:
|
|
434
|
+
|
|
435
|
+
```python
|
|
436
|
+
class InterceptingClient(httpx.Client):
|
|
437
|
+
# constructor
|
|
438
|
+
|
|
439
|
+
def __init__(self, *args, **kwargs):
|
|
440
|
+
self.token_provider = ...
|
|
441
|
+
super().__init__(*args, **kwargs)
|
|
442
|
+
|
|
443
|
+
# override
|
|
444
|
+
|
|
445
|
+
def request(self, method, url, *args, **kwargs):
|
|
446
|
+
headers = kwargs.pop("headers", {})
|
|
447
|
+
headers["Authorization"] = f"Bearer {self.token_provider()}"
|
|
448
|
+
kwargs["headers"] = headers
|
|
449
|
+
|
|
450
|
+
return super().request(method, url, *args, **kwargs)
|
|
451
|
+
|
|
452
|
+
@advice
|
|
453
|
+
class ChannelAdvice:
|
|
454
|
+
def __init__(self):
|
|
455
|
+
pass
|
|
456
|
+
|
|
457
|
+
@around(methods().named("make_client").of_type(HTTPXChannel))
|
|
458
|
+
def make_client(self, invocation: Invocation):
|
|
459
|
+
return InterceptingClient()
|
|
460
|
+
```
|
|
461
|
+
|
|
462
|
+
## FastAPI server
|
|
463
|
+
|
|
464
|
+
In order to expose components via HTTP, the corresponding infrastructure in form of a FastAPI server needs to be setup.
|
|
465
|
+
|
|
466
|
+
|
|
467
|
+
```python
|
|
468
|
+
@module()
|
|
469
|
+
class Module():
|
|
470
|
+
def __init__(self):
|
|
471
|
+
pass
|
|
472
|
+
|
|
473
|
+
server = FastAPIServer(host="0.0.0.0", port=8000)
|
|
474
|
+
|
|
475
|
+
environment = server.boot(Module) # will start the http server
|
|
476
|
+
```
|
|
477
|
+
|
|
478
|
+
This setup will also expose all service interfaces decorated with the corresponding http decorators!
|
|
479
|
+
No need to add any FastAPI decorators, since the mapping is already done internally!
|
|
480
|
+
|
|
481
|
+
## Implementing Channels
|
|
482
|
+
|
|
483
|
+
To implement a new channel, you only need to derive from one of the possible base classes ( `Channel` or `HTTPXChannel` that already has a `httpx` client)
|
|
484
|
+
and decorate it with `@channel(<name>)`
|
|
485
|
+
|
|
486
|
+
The main methods to implement are `ìnvoke` and `ìnvoke_async`
|
|
487
|
+
|
|
488
|
+
**Example**:
|
|
489
|
+
|
|
490
|
+
```python
|
|
491
|
+
@channel("fancy")
|
|
492
|
+
class FancyChannel(Channel):
|
|
493
|
+
# constructor
|
|
494
|
+
|
|
495
|
+
def __init__(self):
|
|
496
|
+
super().__init__()
|
|
497
|
+
|
|
498
|
+
# override
|
|
499
|
+
|
|
500
|
+
def invoke(self, invocation: DynamicProxy.Invocation):
|
|
501
|
+
return ...
|
|
502
|
+
|
|
503
|
+
async def invoke_async(self, invocation: DynamicProxy.Invocation):
|
|
504
|
+
return await ...
|
|
505
|
+
|
|
506
|
+
```
|
|
507
|
+
|
|
508
|
+
# Version History
|
|
509
|
+
|
|
510
|
+
**0.10.0**
|
|
511
|
+
|
|
512
|
+
- first release version
|
|
513
|
+
|
|
514
|
+
|
|
515
|
+
|
|
516
|
+
|
|
517
|
+
|