As a service author I can use the abstractions provided by Spring Cloud Deployer as part of a multi-flow reactive pipeline

[ojhughes]

Currently the Deployer SPI provides non reactive signatures eg String deploy(AppDeploymentRequest request) (see [https://github.com/spring-cloud/spring-cloud-deployer/blob/master/spring-cloud-deployer-spi/src/main/java/org/springframework/cloud/deployer/spi/app/AppDeployer.java]

To use Deployer effectively within a multi-flow reactive pipeline, there would need to be alternative, reactive interfaces provided by the Deployer SPI, eg Mono<String> deploy(AppDeploymentRequest request)

It should be feasible to provide reactive alternatives to the default implementations of the Reactive SPI (Cloud Foundry, Kubernetes, Local)

cc @sabbyanandan

[ojhughes]

The simplest way to achieve this is introducing a new class CloudFoundryAppDeployerOperations that contains all the functionality needed by both the blocking and non-blocking interface.

[ojhughes]

I don't think it is feasible to introduce Reactive versions of the existing S-C-Deployer implementations without the risk of breaking other consumers. This is because a lot of functionality is with an abstract base class

I tried introducing a shared operations class that could be used by both reactive and non-reactive implementations. This quickly started falling apart because a lot of the functionality that would need to be shared via composition exists in the abstract class.

I think it is reasonable to not use Reactor directly to begin with, instead using deployer with an ExecutorService when parallel deployments are required

[ojhughes]

Maybe I wrote this off too early..
There was another discussion about this some time age spring-cloud/spring-cloud-deployer#19

I think my fears about changing the abstract base class could be rectified by removing it completely and replacing with delegate. Would be good to discuss @royclarkson @scottfrederick

[ojhughes]

@royclarkson Do you think it would be possible to remove the .block() call here: https://github.com/spring-cloud/spring-cloud-deployer-cloudfoundry/blob/master/src/main/java/org/springframework/cloud/deployer/spi/cloudfoundry/CloudFoundryAppDeployer.java#L101-L104

[royclarkson]

We can certainly improve that code if we are returning reactive types. IIUC, blocking there was because they wanted the exception thrown. If you are working with imperative expectations, then blocking might be the best option. I'd have to get it loaded up in an IDE and play with it to confirm.