Introduction of finagle 2015 08 01 Scala kansai (Reprint at Oct 14 2017)

Who I am ● iwag / @iwag_org ● Search Team at Dwango Corp. ○ Scala Experience : 1 and half year ● Person who doesn’t care about the compilation time in Scala ● Other technical interests: ○ C++11, Ruby, Elasticsearch, Java8 ○

Overview ● Introduction finagle ● Case study (next presentation) ● Impressions/lessons (next presentation)

What is finagle? ● RPC library in Scala developed by twitter, which attends to extend Future

(Short) history of finalge ● Launched twitter in early 2007 ● (at the moment) Ruby on Rails, monolithic application ● A crisis (often appeared whale!) in 2009 ○ The twitter user soared and broke! ○ Make an effort to change scalable system instead of Rails ● System reform Ruby to Scala(Java) from 2011 ○ https://blog.twitter.com/2011/finagle-a-protocol-agnostic-rpc-syt em ○ http://readwrite.com/2011/07/06/twitter-java-scala ○ Scala 2.9.x era

Finagle is not like ● Web application framework like Play framework, rails ○ Play provides a bunch of features but finagle does only a few ● Network, Distributed System Framework ● A wrapper of netty ● Mysterious functions ○ Stats, serversets...

Central dogma of finagle ● Future/Service/Filter ● Stacks using those concepts ○ Finagle-core ○ Finagle-http ○ finagle-thrift

Future ● Type with value available in Future ○ twitter ‘s developers inspired from Facebook’s C++ library ● Nowadays, Future is a general knowledge for Scala developers, though… ○ Http://docs.scala-lang.org/en/overviews/core/futures.html ○ Fairly different from twitter Future and Scala Future

Service ● Class with a function that returns Future[Rep] and receive Req abstract class Service [Req, Rep] { def apply (req: Req): Future [Rep] }

For Instance of Service ● HTTP Server ○ Service[HttpRequest, HttpResponse] ● Controller in WAF: Service[HttpRequest, HttpResponse] ● MySQL client: Service[MySQLRequest, MySQLResponse] ●

Simple server class Hello extends Service [Request, Response] { override def apply (request: Request): Future [Response] = { val resp = Response () resp.contentString = "Hello" Future (resp) }} object Foo extends App { def main = { Await.all (Httpx.serve ("0.0.0.0: 8080", new

A test of simple server class HelloTest in Specification {"Hellooooo" should { "reply hello" in { val res = Await.result (service (Request ()) res.contentString must _ == "Hello" } } }

Filter ● Filter can convert Req or Rep handling by Service ● Filter [RepI, RepO, ReqO, ReqI]

For example Abstract class Filter [RepI, RepO, ReqO, ReqI] { def apply (r: ReqI, next: Service [ReqO, RepI]): Future [RepO] } OR there’s simple ver. abstract class SimpleFilter [Rep, Rep] { def apply (r: Req, next: Service [Req, Rep]): Future [Rep] }

Combination of Service and Filter val httpStatsFilter = new HttpxStatsFilter [HttpRequest] (stats) val statsFilter = new StatsFilter [HttpRequest, HttpResponse] (stats) val logging = new QueryLoggingFilter () val retry = new RetryingFilter [HttpRequest, HttpResponse] (RetryPolicy.tries (3), new NullTimer) val httpServiceWithFilter: Service [HttpRequest, HttpResponse] = statsFilter andThen httpStatsFilter andThen retry andThen logging andThen mux

When to use ● Filter allows a function plugable ○ We can add/remove a function when we like without modifying core function ○ Like: output logs, retry request, control amount ● Now can concentrate on the core function by separating small filter

Advantage ● No longer care about features unimportant ● Easy to put on or remove it ● Easy to test <- important!

Conclusion ● Introduction finagle ● History ● Central dogma ○ Future ○ Service ○ Filter