Netty, который используется в Finagle, использует конвейер «обработчиков» последовательно обрабатывать входящие и исходящие данные. Примеры Netty и включенные библиотеки показывают различные обработчики, используемые для таких вещей, как аутентификация, протокольные кодеки и реальная бизнес-логика сервиса.

Finagle, похоже, принимает концепцию обработчика и вместо этого напрямую предлагает пользователям кодеки, фильтры и сервисы API. Несмотря на то, что они имеют различные подписи, новым пользователям Finagle остается задача решить, какой из них использовать для реализации каждой части своего общего сервера. Вместо того, чтобы просто решить, где разбить цепочку на различные обработчики Netty, теперь им нужно решить, какая часть должна быть частью кодека, в отличие от любых фильтров, по сравнению с отдельным сервисом в конце цепочки. В итоге, хотя Finagle является библиотекой более высокого уровня, чем Netty, и она должна облегчить задачу построения службы, пользователь API может иметь больше возможностей для выбора.

Каковы ключевые точки решения и плюсы / минусы для размещения определенной части потока обработки в кодеке, а не в фильтре или в единственном сервисе? Если существует вероятность того, что конвейер может быть дополнительно расширен, если вместо этого служебная логика будет помещена в фильтр с помощью «noop» сервис в конце конвейера? Учитывая гибкость в упорядочении фильтров (как обработчиков в конвейере), по сравнению с единичным кодеком на одном конце и обслуживанием на другом конце, почему не следует «все»? быть фильтром?