lsd-consulting / lsd-distributed-interceptors Goto Github PK

Code changes are required for bumping to latest spring - see #41

The upgrade includes breaking changes (just to a unit test I think) so needs a little bit of work

To simplify the naming of services on the sequence diagrams we could accept header values that specify the target or source names. This can help overcome some of the limitations of the current options (e.g. overloaded path names from multiple services)

For the names something like Target-Name and Source-Name seems to be sensible (The X- prefix is now discouraged for custom headers). I don't think we need to add anything to the name that references yatspec or lsd since it's just a generic meta-data that the libraries will happen to use? (what do you think)

The above names match what the (non-distributed) interceptor library currently uses but if we find better names we can change that to be in sync since many projects will use both libs.

• For consistency with the lsd-core library (and others e.g. lsd-interceptors) we can use the ValidComponentName class to convert component names to valid values so that we have consistent naming without needing to duplicate the logic.

This requires either reading the generated HTML file or use something like StringWriter to retrieve interactions from LsdContext.

• It would be useful to make it clear that a message is being replayed or dead-lettered (can be confusing on diagrams otherwise).
• Perhaps looking for keywords on the message headers could help here since we can't easily see the exchange details?

• Request/Response headers would be useful

The LSD generator part needs to be reused in other projects so it makes sense to extract it from this library into a separate one.

I think it will be easier to upgrade to the latest lsd dependencies if this project is converted to kotlin because the builders have been removed so having named parameters could be helpful.

To minimise the library's impact on the application's performance, it would be beneficial to decouple the intercepting from the persisting, possibly at the cost of a slightly bigger memory footprint.

Requirements:

• interceptors should return to the main thread as quickly as possible
• persisting the interactions should be done asynchronously
• the size of the storage for intercepted interaction should be bounded
• in case the storage is at capacity, the intercepting should not be affected (non-blocking)

It would be super useful if we could have the request headers available on the response interactions. This is so that the Source-Name and Target-Name headers are available when we determine the source and destination mappings (since the headers aren't copied to the response message).

Other options include merging all headers together but that feels a bit dirty and may cause confusion. Storing both sets of headers may even provide additional info for troubleshooting in addition to solving the missing Source-Name and Target-Name header problem.

Synchronous respones (e.g. http sync responses) can be marked explicitly. This is useful for styling purposes and also be be filtered out from the component diagrams.

For the DSL syntax it just needs the sync keyword as a prefix e.g.

sync response from A to B

or alternatively with the builder e.g.:

SynchronousResponse.builder()
    .id(123)
    .label("A synchronous response")
    .from("A")
    .to("B")
    .data("200 OK")
    .build()
`

The MongoDB instance that is span up during integration tests needs to be shut down at the end.

This becomes problematic as soon as there is more than 1 integration test using that instance and one or more unit tests that don't use it.

The problems are:

• when to spin it up?
• when to shut it down?

A number of approaches have been tried and all seem to cause problems.

The best so far has been to implement a jUnit5 listener which spins it up before all the tests and shuts it down after all the test. This, however, caused problems with Pitest.

The next one I can think of is to move those integration tests to a separate source set.

• Maybe by default sensitive data could be obfuscated with an optional property to disable this if necessary
• Probably more of an issue in higher environments assuming this may be used outside of dev environments

Follow the lsd-core example

Some notes for things to fix the diagrams:

• Add missing @ExtendWith
• Figure out why some popups aren't working (may be a yatspec bug)
• Why are some interactions missing (or should yatspec handle the missing values better)

Spring now supports Kafka, RabbitMQ etc message handling with a functional approach through Spring Cloud Stream.

It would be helpful if this library supported intercepting messages handled by SCS.