Introduction of finagle

1. Introduction of finagle 2015 08 01 Scala kansai (Reprint at Oct 14 2017)
2. 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 ◦
3. Overview • Introduction finagle • Case study (next presentation) • Impressions/lessons (next presentation)
4. What is finagle? • RPC library in Scala developed by twitter, which attends to extend Future
5. (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
6. 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...
7. Central dogma of finagle • Future/Service/Filter • Stacks using those concepts ◦ Finagle-core ◦ Finagle-http ◦ finagle-thrift
8. 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
9. Service • Class with a function that returns Future[Rep] and receive Req abstract class Service [Req, Rep] { def apply (req: Req): Future [Rep] }
10. For Instance of Service • HTTP Server ◦ Service[HttpRequest, HttpResponse] • Controller in WAF: Service[HttpRequest, HttpResponse] • MySQL client: Service[MySQLRequest, MySQLResponse] •
11. 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
12. A test of simple server class HelloTest in Specification {"Hellooooo" should { "reply hello" in { val res = Await.result (service (Request ()) res.contentString must _ == "Hello" } } }
13. Filter • Filter can convert Req or Rep handling by Service • Filter [RepI, RepO, ReqO, ReqI]
14. 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] }
15. 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
16. 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
17. Advantage • No longer care about features unimportant • Easy to put on or remove it • Easy to test <- important!
18. Conclusion • Introduction finagle • History • Central dogma ◦ Future ◦ Service ◦ Filter