[posts] [talks] [rss]
Futures: Twitter vs. Scala
Scale By the Bay 2017 in San Francisco, Nov 2017 | video slides

It's been enough of confusion around Twitter Futures. Let's clear the air and talk frankly about historic and technical reasons they exist. We'll see how the difference in the API, behavior, and performance not only makes Twitter Futures competitive with Scala Futures but also the obvious choice for IO systems with the corresponding degree of throughput requirements (i.e., Finagle).

Finch: Put Some Types on Your HTTP Endpoints
ScalaMatsuri 2017 in Tokyo, Feb 2017 | video slides transcript

Finch (a Scala combinator library for building HTTP endpoints) is rapidly approaching 1.0 and while its design keeps evolving, the core principles are still the same as in 0.1. In this talk, we’ll walk through Finch’s only abstraction, an Endpoint, and discuss why building an HTTP API in terms of functional combinators is a reasonable idea that promotes an insane level of reusability. We’ll see that functional abstractions and APIs don’t necessary trade off performance, but could easily be orthogonal to it.

Finagle Under the Hood
ScalaDays 2016 in NY, May 2016 | video slides transcript

Finagle is an extensible RPC system for JVM written in Scala that is used and developed at Twitter. It promotes a programming model where servers and clients might be viewed as functions, which are both easy to compose and reason about. Although, there is quite a complex logic (connection pooling, load balancing, circuit breaking and so on) hidden behind those functions. In this talk, we'll dig into Finagle internals and carefully walk through each of its modules to see what happens when we a) send a request to a Finagle client b) receive a request by a Finagle server.

Finch: Your REST API as a Monad
ScalaX in London, Dec 2015 | video

Finch is a purely-functional library for building composable REST APIs on top of Finagle. It's well known and widely adopted in Finagle that "Your Server as a Function" uses Request => Response. In a REST API setting this function may be viewed as Request =1=> (A =2=> B) =3=> Response, where transformation 1 is request decoding (deserialization), transformation 2 -is business logic and transformation, and transformation 3 is- response encoding (serialization). The only interesting part here is transformation 2 (i.e., A => B). Since it's usually a challenge to deal with pure functions in real-world problems, we wrap this into a monad M[_], so that a transformation (i.e, map, flatMap) M[A] => M[B] encodes the business logic of a REST API server. This and other ideas are implemented in Finch, a purely-functional library for building composable REST APIs on top of Finagle.

Purely Functional Data Structures in Scala
@ScalaNSK, Sep 2013 | video slides

An overview of the ideas and tricks used to implement classic data structures in a purely functional setting. See Scalacaster project for the source code snippets.

Archive (outdated talks)
Copyright 2014-2018
Vladimir Kostyukov