Extracting the Delivery Service - Step 4: using new `Delivery Service`

This article describes the fourth step in the process of extracting the Delivery Service from the FTGO application monolith. The previous articles are as follows:

After step 3, the Delivery Service is deployed but unused. The fourth step is to route production traffic to the Delivery Service.

First, we must change the FTGO application’s order management logic to invoke the service to schedule, and cancel deliveries. This is accomplished by defining a DeliveryServiceProxy class, which implements the DeliveryService, and sends command messages to the Delivery Service.

Second, we must route some requests from the courier’s mobile application to the Delivery Service instead of the FTGO application This is accomplished by introducing an API gateway that routes requests to either the FTGO application or the Delivery Service.

The following diagram shows the revised architecture.

Module structure

The following diagram shows the new module structure:

There are two new modules:

ftgo-api-gateway - implements the API Gateway
ftgo-delivery-service-proxy - contains the DeliveryServiceProxy class

Lets look at each of the changes starting with the DeliveryServiceProxy class.

The `DeliveryServiceProxy` class

The FTGO application’s order management logic invokes delivery management via the DeliveryService interface. The DeliveryServiceProxy class, which is in the ftgo-delivery-service-proxy module, implements that interface by sending command messages to the Delivery Service using the Eventuate Tram Command API:

public class DeliveryServiceProxy implements DeliveryService {

  @Override
  public void scheduleDelivery(LocalDateTime readyBy, Long orderId, long restaurantId, Address deliveryAddress) {
    String commandId = commandProducer.send(DeliveryServiceChannels.DELIVERY_SERVICE_CHANNEL,
            new ScheduleDelivery(readyBy, orderId, restaurantId, deliveryAddress),
            "Dont_Care",
            Collections.emptyMap());
  }

...

Let’s now look at how the @Bean for the DeliveryServiceProxy is configured.

Toggling between the old and new implementations of delivery management

We could simply define an @Bean for the DeliveryServiceProxy in one of the FTGO application’s @Configuration classes. However, when extracting functionality into a service, it’s often useful to be able to switch back to the old implementation when unexpected errors occur. In this particular example, we can use the Spring framework’s profile mechanism to implement a feature flag for toggling between the old and new implementations of delivery management.

There are two @Configuration classes in the ftgo-delivery-service-proxy module The first configures the FTGO application to use the DeliveryServiceProxy. It’s only enabled when the RemoteDeliveryService profile is active.

@Configuration
@Import(TramCommandProducerConfiguration.class)
@Profile("RemoteDeliveryService")
public class DeliveryServiceRemoteConfiguration {

  @Bean
  public DeliveryService deliveryServiceProxy(CommandProducer commandProducer) {
    return new DeliveryServiceProxy(commandProducer);
  }
}

The second @Configuration configures the FTGO application to use the existing embedded delivery management logic. It’s enabled when the RemoteDeliveryService profile is not active.

@Configuration
@Import(DeliveryServiceWebConfiguration.class)
@Profile("!RemoteDeliveryService")
public class DeliveryServiceEmbeddedConfiguration {
}

Both @Configuration classes are @Imported by FtgoApplicationMain:

@Configuration
@EnableAutoConfiguration
@Import({
        ...
        DeliveryServiceEmbeddedConfiguration.class,
        DeliveryServiceRemoteConfiguration.class,
        ...
        })
public class FtgoApplicationMain {
...

With these two @Configuration classes defined, the FTGO application will only use the Delivery Service when the RemoteDeliveryService profile is active. We can, for example, activate the profile using -Dspring.profiles.active=RemoteDeliveryService on the command line or by setting the SPRING_PROFILES_ACTIVE=RemoteDeliveryService environment variable.

API gateway

The API gateway, which is implemented by the ftgo-api-gateway module, routes requests to either the Delivery Service or the FTGO application. Specifically, it routes all requests to the FTGO application except for those handled by the Delivery Service’s DeliveryController.

The API gateway is built using Spring Cloud API Gateway. The ApiGatewayConfiguration @Configuration class defines a RouteLocator @Bean, which configures the routes.

@Configuration
@EnableConfigurationProperties({ApiGatewayDestinations.class})
public class ApiGatewayConfiguration {

  @Bean
  public RouteLocator routing(RouteLocatorBuilder builder, ApiGatewayDestinations apiGatewayDestinations) {
    return builder.routes()

            // route to Delivery Service - DeliveryController

            .route(r -> r.path("/couriers/**/availability").uri(apiGatewayDestinations.getDeliveryServiceUrl()))
            .route(r -> r.path("/orders/**/pickedup").uri(apiGatewayDestinations.getDeliveryServiceUrl()))
            .route(r -> r.path("/orders/**/delivered").uri(apiGatewayDestinations.getDeliveryServiceUrl()))

            // everything else goes to monolith

            .route(r -> r.path("/**").uri(apiGatewayDestinations.getFtgoApplicationUrl()))
            .build();
  }

}

End-to-end testing

Because the FTGO application can either use the old, embedded delivery management logic or the new Delivery Service, there are two versions of the end to end tests.

monolith (./build-and-test-ftgo-monolith.sh) - deploys the FTGO application along with the necessary infrastructure services and tests the monolith’s REST API.
microservices (./build-and-test-ftgo-microservices.sh) - deploys the FTGO application, Delivery Service and API Gateway and make HTTP requests to the API Gateway.