The session will be about Twitter's RPC Library, Finagle. We well see why Finagle is a powerful library for asynchronous programming and will have a working implementation of simple use case.

1. Presented By: Rahul Kayal
Introduction to Twitter’s
Finagle

2. What is Finagle?
Twitterʼs definition - Finagle is an extensible RPC for JVM, used to construct high
concurrency servers. Finagle implements uniform client and server APIʼs for several
protocols, and is designed for high performance and concurrency. Most of Finagleʼs
code is protocol agnostic, simplifying the implementation of new protocols.
In simple words - Finagle is a network stack for the JVM that you can use asynchronous
Remote Procedure Call (RPC) clients and server.

3. Why do we need Finagle?
In an actual enterprise application, there are a lot of services and each have them
have their own protocol. Each of these protocols comes with their libraries, jars to
manage them

4. Challenges
● Load Balancers
● Failure Detection
● Low Latency
● High Throughput
● Metric Collections
● Sharding
● Service Discovery
● Routing
● Back-Pressure Management
● Distributed Tracing
Twitterʼs Finagle core library consolidates all these and provides a single solution
for all these problems.

5. Finagle an be divided in 2 parts
Part 1 : As an asynchronous framework - Handled by Finagleʼs
com.twitter.util.Future.
Part 2 : As a common infrastructure to RPC Servers and Clients.

6. Three Composible Primitives
For asynchronous RPC development, there are 3 basic constructs we need to know.
● Service
● Future
● Filter

7. Service
● The core abstraction of Finagle is that of a Service. A Service, at its heart, is a
simple function, taking 2 arguments and returning a Future.
● A Service handles RPCs, taking requests and gives back a Future representing
the eventual result (or failure) of Type response.
● Services are used to represent both client and server. An instance of service is
used through a client; a server implements a Service.
● Services implement application logic. We might, for instance, define a
Service<Request,Response> to implement our applicationʼs external API.

8. Server
● Finagle Server implements a simple interface Server.
● When given a socket address and a ServiceFactory, a server returns a
ListeningServer when the serve method is called. The ListeningServer allows
management of server resources.
● The interface comes with variants that allow serving a simple Service as well.
● Typical usage would be of the form : Protocol.serve(...)
● Example : Http.server().serve(“:8080, service)

9. Server Modules
● Finagle servers are simple as they are designed to serve requests quickly. Hence,
Finagle minimally furnishes servers with additional behaviour. More
sophisticated behaviour lives with the clients.

10. Clients
● Similar to Servers, Finagle clients adhere to a simple interface for construction.
● Finagle supports both stateful and stateless clients.
● For stateless client, the usage is Protocol.client().newService(destination). The
method returns a Service. Dispatched requests will be load balanced across all of
the resolved hosts utilizing Finagleʼs configured Load Balancer.
● For stateful client, the usage is Protocol.client().newClient(destination). This
method would return a ServiceFactory that represents a distinct session.
Requests dispatched on this Service will reuse the established connection.

11. Client Contd.
● Load Balancer works only per session using ServiceFactory.apply, while
per-request on newService.
● Depending on the connection pooling strategy, Service.close returns the
connection to the pool and does not necessarily kill the connection. Hence it is
important to close the sessions after use to avoid resource leakage.

12. Finagle Client Features
● Connection Pooling
● Load Balancing
● Failure Detection
● Failover/Retry
● Distributed Tracing
● Service Discovery
● Rich Statistics
● Native OpenSSL bindings

13. Finagle Server Features
● Backpressure
● Server Registration
● Distributed Tracing
● Native OpenSSL bindings

14. FUTURES
● A computation that is not yet completed. Itʼs a promise of something to be done
later.
● It is implemented usually by either non-blocking io or thread pools. Finagle
almost entirely uses non blocking code.
● Finagle uses Futures to encapsulate and compose concurrent operations such as
network RPCs.
● The response of the Service is a Future, hence the response of a Client call to RPC
is a Future and we can make asynchronous calls to the server.

15. Filters
● Filters are basically that transforms a service.
● Like Services, Filters are also simple function.
● Filter also enable decomposition of services into phases.
● Provide service generic functionality, like rate limiting.
● A common example is to implement timeouts : if a request fails to complete
within a certain time, the timeout mechanism fails it with a timeout exception.
● It also returns a Future for non-blocking operations.

16. Demo
● Finagle Server and service
● Finagle Client and service
● Filters
● Future

17. Finagle a Network Stack for JVM

18. Thank You !
Get in touch with us:
Lorem Studio, Lord Building
D4456, LA, USA