vkostyukov

GET JSON ARRAY

Benchmark                                   Mode Cnt          Score       Error   Unit

FinchCirce.getArr                           avgt  10         24.846 ±     0.678  ms/op
FinchCirce.getArr:·gc.alloc.rate.norm       avgt  10  183890756.229 ± 11616.394   B/op
FinagleJackson.getArr                       avgt  10         16.358 ±     1.075  ms/op
FinagleJackson.getArr:·gc.alloc.rate.norm   avgt  10  166581859.626 ± 14922.873   B/op

vkostyukov

The [Future Finch][1] writeup defines a vector in which Finch 1.0 should be developed. The goal for 1.0 is to build very clean, simple, well-tested and composable core based on purely functional constructs and immutable data. The core will provide a solid ground for the micro-frameworks, which should land in Finch 2.0.

This document consists of two parts. The first part presents a high-level picture of Finch 1.0. The second part describes required steps we, Finch contributors and maintainers, have to make in order to bring the library to its first stable version.

One Abstraction to Rule Them All

Looking at the current API, one can find a slight correlation between Routers and RequestReaders. They both take a request and produces a value of type A from it. They both functions: HttpRequest => A. Keeping that in mind, [the idea of composing them ][2] into a single thing (perhaps Router) has found its supporters. The next reasonable step would be to completely merge those abstractions into a sing

vkostyukov

Future Finch

Finch has just reached version 0.7 and we're still months from the first "stable" version (in quotes, since Finch has always been pretty stable: minimal and reasonable API changes, no major bugs/regressions found since 0.1) but's a very good time for us to look around and see where to swim.

This write-up is not a roadmap for 1.0, it's mostly an attempt to analyze Finch's Future and to choose a direction in wich the roadmap to 1.0 will be defined.

Low-Level Finch

While, Finch is built using purely functional abstractions, it's still might be described as "low-level" framework or library. Finch doesn't give the developers an answer on very simple question: "How to organize my codebase?". Frameworks usually answer it pretty well - "Here is the controller class. Implement those methods and you're all set.". Helping the developers with this sort of questions is clearly a major priority for Finch. Although, this doesn't mean that Finch will [be a framework][1] one day. The project philosophy wi

vkostyukov

package io.finch.playground

import com.fasterxml.jackson.databind.ObjectMapper
import com.fasterxml.jackson.module.scala.DefaultScalaModule
import com.twitter.finagle.{Service, Filter, Httpx}
import com.twitter.util.{Future, Await}

import io.finch.{Endpoint => _, _}
import io.finch.micro._
import io.finch.request._

vkostyukov

/**
 * A standard binary min-heap based on http://arxiv.org/pdf/1312.4666v1.pdf
 */
sealed trait Heap[+A] {
  def min: A

  def left: Heap[A]
  def right: Heap[A]
  def isEmpty: Boolean

vkostyukov

trait %>[From, To] {
  def apply(x: From): To
}

def view[From, To](f: From => To): From %> To = 
  new %>[From, To] { 
    def apply(x: From): To = f(x) 
  }

implicit i: Int %> String = view(_.toString)

vkostyukov

trait M[R, A] { self =>
  def apply(r: R): A

  def map[B](f: A => B): M[R, B] = new M[R, B] {
    def apply(r: R): B = f(self(r))
  }

  // left associativity
  def flatMap[S, B](f: A => M[S, B])(implicit ev: S <:< R): M[S, B] =
    new M[S, B] {

vkostyukov

trait R[+A] { self =>
  type In

  def apply(in: In): A

  def map[B](f: A => B): R[B] = new R[B] {
    type In = self.In
    def apply(in: In) = f(self(in))
  }

vkostyukov

// A type for a composite value
case class ~[+A, +B](a: A, b: B)

// An applicative functor
trait F[+A] { self =>
  def value: A
  def ~[B](that: F[B]): F[A ~ B] = new F[A ~ B] {
    def value: A ~ B = new ~(self.value, that.value)
  }
}

vkostyukov

History

There is a bunch of tickets/PRs related to the same underlying problem. It has started with two tickets:

• [Issue 190][0] - composing routers with filters and services
• [Issue 172][1] - mixing futures and services in the same endpoint/router

Then Jens has created a [PR 184][2] that indicated a problem of domain types in Finch. So, I created an [issue 204][3] to track the progress on this direction. More importantly, I've posted a first version of possible solution for the "Finch in Action" problem in [PR 206][4]. This document mostly describes an approach called "Micro Finch", that in my opinion solves the original problem.

The "Finch in Action" Problem