Netty, que se usa dentro de Finagle, usa una tubería de "manejadores" para procesar secuencialmente los datos enlazados de entrada y salida. Los ejemplos de Netty, y las bibliotecas incluidas, muestran varios manejadores utilizados para cosas como la autenticación, los códecs de protocolo y la lógica de negocios real del servicio.

Finagle parece tomar el concepto de controlador, y en su lugar, ofrece directamente a los usuarios de API codecs, filtros y servicios. Si bien estos tienen diferentes firmas, los nuevos usuarios de Finagle se quedan con las tareas de decidir cuál usar para implementar cada parte de su servidor en general. En lugar de simplemente decidir dónde dividir la cadena en varios manejadores Netty, ahora tienen que decidir qué parte debe ser parte de un códec, frente a cualquier filtro, versus el servicio singular al final de la cadena. En resumen, aunque Finagle es una biblioteca de mayor nivel que Netty, y debería facilitar la tarea de construir el servicio, el usuario de la API puede tener más opciones que hacer.

¿Cuáles son los puntos de decisión clave, y las ventajas y desventajas, para colocar una parte particular del flujo de procesamiento en un códec frente a un filtro frente a un servicio singular? Si existe la posibilidad de que la canalización se extienda más, ¿se debería colocar la lógica de servicio en un filtro en su lugar, con un servicio "noop" al final de la tubería? Dada la flexibilidad para ordenar filtros (como manejadores en la tubería), en comparación con el códec singular en un extremo y el servicio en el otro, ¿por qué "todo" no debe ser un filtro?