proposal: combination of modules

I’ve just started using resilience4j today so I may be wrong on that… but what to me seems missing and that I have had to implement myself right now is a combinatory class with multiple “resilient” interfaces to get the desired behaviour… I mean , here we have a lot of classes but for a real scenario request, one usually need more than one of these combined… ie : a external call to a api would usually require: circuitBreaker { timeLimiter { retry { CALL } } } in this case the timeLimiter is outside the retry because should not be retried ( and also create a sort of higher cap on retry calls time + CALL time ) this is just one scenario but maybe composability may be usefull in other scenarios too … everything probably should be designed and abstracted with a single handler which also may influcence the metrics/tagging features…

for my very specific usecase I’ve just wrapped callbacks in a class ( which also could be injected as single dependency )

class ResilienceComboImpl(val retry : Retry?,
                          val circuitBreaker: CircuitBreaker?,
                          val timeLimiter  : TimeLimiter?) : ResilienceCombo {

    override suspend fun <R>wrapCBR( block : suspend () -> R ) : R?{
        circuitBreaker ?: throw Exception("Circuit breaker not provided")
        retry ?: throw Exception("Retry not provided")
        return circuitBreaker.executeSuspendFunction{
                retry.executeSuspendFunction {
                    block()
                }
        }
    }
    override suspend fun <R>wrapCBRT( block : suspend () -> R ) : R?{
        circuitBreaker ?: throw Exception("Circuit breaker not provided")
        timeLimiter ?: throw Exception("Timelimiter not provided")
        retry ?: throw Exception("Retry not provided")
        return circuitBreaker.executeSuspendFunction{
            timeLimiter.executeSuspendFunction {
                retry.executeSuspendFunction {
                    block()
                }
            }
        }
    }
}

but this is far away from being something shareable in public code, I’ve just pasted here to give you some code in order to capture your attention 😃

[hexmind]

Resilience4j promotes a decorator pattern for one or (especially) more resilience components. They are like layers. However because Java functional interfaces are first-class citizens for this library you can also compose your decorators using methods compose/andThen from Function class. Maybe Decorators class (example usage below) can meet your expectations? Fluent interface looks more readable and developer friendly than exceptions throwing. You can also hide this code into your custom class and provide specific constructor for required components.

Supplier<String> decoratedSupplier = Decorators.ofSupplier(supplier)
  .withRetry(retry)
  .withCircuitBreaker(circuitBreaker)
  .withBulkhead(bulkhead)
  .decorate();

[fvigotti]

Yes this is somwehat what I had in mind, I have now seen that this example exists in the guide, but I thought that this Decorators interface was still missing because the package resilience4j-all isn’t specified in docs nor in guide, I’ve seen that in maven but when importing… who want it all ? maybe resilience4j-common or resilience4j-decorators if only contains that is a better name? anyway this seems to solve the problem, even if I’ve yet to adapt for kotlin coroutines , also the ordering of the decoration is important but not documented well I’ll have to reason that around the source code …

I’m going to close this , but I’ll add more comments if I find something usefull 😃 thank you, Francesco