Netty, który jest używany w Finagle, używa potoku „programów obsługi” do sekwencyjnego przetwarzania danych wejściowych i wyjściowych. Przykłady Netty i dołączone biblioteki pokazują różne procedury obsługi używane do takich rzeczy, jak uwierzytelnianie, kodeki protokołów i rzeczywista logika biznesowa usługi.

Finagle wydaje się przyjmować koncepcję obsługi i zamiast tego oferuje bezpośrednio kodeki, filtry i usługi dla użytkowników interfejsu API. Chociaż mają różne podpisy, nowi użytkownicy Finagle mają zadanie decydowania, którego użyć, aby zaimplementować każdą część swojego całego serwera. Zamiast decydować, gdzie rozbić łańcuch na różne programy obsługi Netty, muszą teraz zdecydować, która część powinna być częścią kodeka, w porównaniu z dowolnymi filtrami, w porównaniu do pojedynczej usługi na końcu łańcucha. Podsumowując, chociaż Finagle jest biblioteką wyższego poziomu niż Netty i powinno ułatwić zadanie zbudowania usługi, użytkownik API może mieć więcej możliwości wyboru.

Jakie są kluczowe punkty decyzji oraz zalety / wady, dotyczące umieszczenia określonej części strumienia przetwarzania w kodeku w porównaniu z filtrem w stosunku do usługi pojedynczej? Jeśli istnieje możliwość dalszego rozszerzenia potoku, czy zamiast tego logika usługi powinna zostać umieszczona w filtrze, z usługą „noop” na końcu potoku? Biorąc pod uwagę elastyczność w zamawianiu filtrów (jako programów obsługi w potoku), w porównaniu z pojedynczym kodekiem na jednym końcu i usługą na drugim końcu, dlaczego nie „wszystko” nie powinno być filtrem?