Netty, который используется в Finagle, использует конвейер "обработчиков" для последовательной обработки входящих и исходящих данных. Примеры Netty и включенные библиотеки показывают различные обработчики, используемые для таких вещей, как аутентификация, протокольные кодеки и фактическая бизнес-логика службы.
Finagle, по-видимому, использует концепцию обработчика, а вместо этого напрямую предлагает кодеки, фильтры и службы API-пользователей. В то время как у них есть разные подписи, новым пользователям Finagle оставлены задачи по решению, которые следует использовать для реализации каждой части своего общего сервера. Вместо того, чтобы просто решать, где разбить цепочку на различные обработчики Netty, теперь им нужно решить, какая часть должна быть частью кодека, по сравнению с любыми фильтрами, по сравнению с уникальной службой в конце цепочки. В целом, хотя Finagle является библиотекой более высокого уровня, чем Netty, и должен облегчить задачу создания службы, у пользователя API может быть больше возможностей сделать.
Каковы ключевые точки принятия решений и плюсы/минусы для размещения определенной части потока обработки в кодеке против фильтра против сингулярного сервиса? Если есть вероятность того, что трубопровод может быть расширен дальше, если вместо этого логика обслуживания будет помещена в фильтр, с услугой "noop" в конце трубопровода? Учитывая гибкость в упорядочении фильтров (в качестве обработчиков в конвейере), по сравнению с единственным кодеком на одном конце и службой на другом конце, почему бы не "все" быть фильтром?