|
| 1 | +--- |
| 2 | +sidebar_position: 70 |
| 3 | +--- |
| 4 | + |
| 5 | +# Behind the scenes |
| 6 | + |
| 7 | +The following paragraphs describe how springwolf works internally. |
| 8 | + |
| 9 | +## Big Picture |
| 10 | +When the Spring Boot application is started, springwolf uses its scanners to find defined consumers and producers within the application. |
| 11 | +Based on the results, the channels/topics are extracted including payload type and merged together into an [AsyncApi conform document](https://www.asyncapi.com/docs/reference/specification/v2.6.0). |
| 12 | + |
| 13 | +The AsyncApi document is accessible an endpoint. |
| 14 | +When the springwolf ui is opened, the browser fetches the document and renders it (see demo). |
| 15 | + |
| 16 | +When publishing is enabled, the user can publish a message through the ui to another endpoint. |
| 17 | +From there, springwolf forwards the message to the protocol specific producer. |
| 18 | + |
| 19 | +## Plugins |
| 20 | +`springwolf-core` provides the base functionality to orchestrate the scanning and building of the AsyncApi document. |
| 21 | +The different protocol (AMQP, Kafka) are supported through plugins. |
| 22 | +These plugins are found through the Spring dependency injection functionality. |
| 23 | +When building own scanner plugins, your plugin will need to implement the `ChannelsScanner` interface. |
| 24 | + |
| 25 | +## Scanners |
| 26 | +`springwolf-core` runs all scanners and merges the found results together into one AsyncApi document. |
| 27 | +When the same channel/topic is found multiple times, it is merged as well. |
| 28 | + |
| 29 | +The result is a [`ChannelItem`](https://www.asyncapi.com/docs/reference/specification/v2.6.0#channelItemObject). |
| 30 | +The `ChannelItem` contains the `Message` for the subscribe and/or publish operation. |
| 31 | + |
| 32 | +## Building an example payload |
| 33 | +When the scanners scan and build the result, they also extract the payload type. |
| 34 | +The payload is registered in the `SchemasService`, which allows to split the `Message` from the schema definition - within the AsyncApi doc a `$ref` references is used. |
| 35 | + |
| 36 | +Using `swagger-inflector` any class can be converted into a OpenApi schema. |
| 37 | +This is used to instantiate an Example object with default values and serialized into an example json for the AsyncApi document. |
| 38 | + |
| 39 | +By using `swagger-inflector`, all the `@Schema` and other swagger annotations are supported as well as `@JsonProperty` through the use of the objectmapper. |
| 40 | + |
| 41 | +### ModelConverters |
| 42 | +ModelConverters provide a way to improve documentation for classes, which cannot be modified, for example because they are part of an external library. |
| 43 | +They follow the same plugin model. |
| 44 | + |
| 45 | +## Putting it all together |
| 46 | +The `AsyncApiService` collects all the channels, schemas and general info and builds the AsyncApi document. |
| 47 | +The controller access this services to serve the document to the ui. |
0 commit comments