How should Armeria provide a way to specify per-route configuration?

[trustin]

When a Service serves more than one Route (e.g. GrpcService, SamlService or any ServiceWithRoutes), it sometimes wants to use different configuration properties for some of its routes. For example, a user might want to specify a different BlockingTaskExecutor or timeout for a certain gRPC method that takes longer time than others.

I have a few options in mind:

1. Add a new default method to Service so that a service can provide an alternative ServiceConfig:

   interface Service {
     ...
     default ServiceConfig getConfig(RoutingContext ctx, ServiceConfig baseConfig) {
       return baseConfig;
     }
   }
   

   If a Service wants to override a certain configuration property, it could override the method like the following:

   class MyService extends HttpService {
     @Override
     public ServiceConfig getConfig(RoutingContext ctx, ServiceConfig baseConfig) {
       if (ctx.path().startsWith("/special/path")) {
         return baseConfig.mutate(builder -> {
           builder.blockingTaskExecutor(specialBlockingTaskExecutor);
         });
     }
   }
   

   • Pros:
     • Can implement without making too many changes.
   • Cons:
     • It can create too many ServiceConfig instances, i.e. poor performance.
2. Copy all service-level configuration properties to ServiceRequestContext and add setters.
   • Pros:
     • Can implement without making too many changes.
   • Cons:
     • This has a risk of making the context API over-crowded.
3. Make it less dynamic by allowing only per-route customization. For example, we could modify HttpServiceWithRoutes.routes() to return Set<RouteConfig> in lieu of Set<Route>.

   interface RouteConfig {
     Route route();
     ServiceConfigProvider serviceConfigProvider();
   }
   
   interface ServiceConfigProvider {
     // Provide the getters for all overridable properties.
     // Default implementations all return `null`, meaning 'use the base config'.
     @Nullable
     BlockingTaskExecutor blockingTaskExecutor(RoutingContext ctx) {
       return null;
     }
   }

   • Pros:
     • Less performance issues than the option 1.
   • Cons:
     • Deprecation and/or breaking changes required. Should we replace ctx.serviceConfig() with ctx.routeConfig()? Should we remove ServiceConfig.route()?
4. Reconsider the ServiceWithRoutes interface. Make it very clear that each Service has only one route and its configuration is determined statically.
   • Replace the services such as GrpcService and THttpService with List<GrpcService> and List<THttpService> where each element serves only one method.
   • We could even rename Service into RouteHandler to make this relationship even clearer.
   • Pros:
     • Probably the simplest and cleanest API.
     • We can deprecate and/or remove ServiceWithRoutes.
     • Configuration API stays same.
   • Cons:
     • You need to build and bind multiple services for gRPC, SAML or any service that serves multiple routes.

For now, I prefer the option 4, which delves into:

• Deprecate ServiceWithRoutes and its subtypes
• Deprecate GrpcService.build() and SamlServiceProvider.newSamlService() in favor of the alternative that returns Map<Route, ...>.

.. but I'd be happy to get more ideas and input to explore more options.