Http4s Guides

You don't need to install anything else other than just Nix https://nixos.org/ :

• Nix sh <(curl -L https://nixos.org/nix/install) If you're using macOS Catalina follow https://nixos.org/manual/nix/stable/#sect-macos-installation

To make sure our dev environment is 100% reproducible, please lock the nix channel to a fix version:

~ nix-shell -p sbt
> sbt new jcouyang/http4s.g8

You can either answer all those question that it prompt or press Enter all the way to the end.

Before we start to build the joke service, what we first is to design a database table, to store the detail of jokes.

You might ask, where is our local DB?

The Postgres DB is defined in docker-compose.yml for local development

db:
  image: postgres:10
  environment:
    - POSTGRES_DB=joke
    - POSTGRES_HOST_AUTH_METHOD=trust
  ports:
    - 5432:5432

Where POSTGRES_DB=joke will help creating the database and name it joke.

You don't need to run DB migration manually most of the time, since nix-shell hook will run it for you.

shellHook = ''
          set -a
          source app.env
          set +a
          source ops/bin/deps-up
          sbt 'db/run migrate'
          cat ops/sbt-usage.txt
          set +e
          '';

Every time you enter nix-shell, you will see the migration log:

nix-shell
Creating network "http4s-example_default" with the default driver
Creating http4s-example_zipkin_1 ... done
Creating http4s-example_db_1     ... done
[info] welcome to sbt 1.3.13 (Azul Systems, Inc. Java 1.8.0_202)
[info] loading settings for project http4s-example-build from plugins.sbt,metals.sbt ...
[info] loading project definition from /Users/jichao.ouyang/Develop/http4s-example/project
[info] loading settings for project root from build.sbt ...
[info] set current project to http4s-example (in build file:/Users/jichao.ouyang/Develop/http4s-example/)
[info] running Main migrate
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.license.VersionPrinter printVersionOnly
INFO: Flyway Community Edition 6.5.5 by Redgate
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.database.DatabaseFactory createDatabase
INFO: Database: jdbc:postgresql://localhost:5432/joke (PostgreSQL 10.14)
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.command.DbValidate validate
INFO: Successfully validated 1 migration (execution time 00:00.015s)
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory create
INFO: Creating Schema History table "public"."flyway_schema_history" ...
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.command.DbMigrate migrateGroup
INFO: Current version of schema "public": << Empty Schema >>
Sep 14, 2020 12:14:15 PM org.flywaydb.core.internal.command.DbMigrate doMigrateGroup
INFO: Migrating schema "public" to version 1.0 - CreateJokeTable

To manually migrate when schema changed:

> sbt "db/run migration"

Migration file located in db/src/main/scala/db/migration

~ tree db/src
db/src
└── main
    └── scala
        ├── DoobieMigration.scala
        ├── Main.scala
        └── db
            └── migration
                └── V1_0__CreateJokeTable.scala

A migration file is actually a Scala doobie source code.

class V1_0__CreateJokeTable extends DoobieMigration {
  override def migrate =
    sql"""create table joke (
                id serial not null
                        constraint joke_pk
                        primary key,
                text text not null,
                created timestamptz default now() not null
          )""".update.run
}

The prefix V1_0__ in class name means version 1.0, detail of naming convention please refer to Flyway

Now we have database scheme set, next we need an API to save data into the new table.

To be to able to save data, a database library such as Doobie or Quill is required.

The following example uses Quill:

 1: val CRUD = AppRoute {                               // <- (route)
 2:     case req @ POST -> Root / "joke" =>
 3:       for {
 4:         has <- Kleisli.ask[IO, HasDatabase]         // <- (kleisli)
 5:         joke <- Kleisli.liftF(req.as[Repr.Create])  // <- (reqbody)
 6:         id <- has.transact(run(quote {              // <- (quill)
 7:           query[Dao.Joke]
 8:             .insert(_.text -> lift(joke.text))
 9:             .returningGenerated(_.id)
10:         }))
11:         _ <- log.infoF(s"created joke with id $id")
12:         resp <- Created(json"""{"id": $id}""")
13:       } yield resp
14: }

1. AppRoute is simply a wrapper of Http4s' HttpRoutes.of[IO] but dependencies injectable.
2. Kleisli.ask is something like @Inject in Java world except everything is lazy, when you ask[IO, HasDatabase], it will <- a instance has of HasDatabase type Kleisli is also known as ReaderT https://blog.oyanglul.us/scala/into-the-readert-verse
3. We also need to read the body from the req using Http4s DSL req.as[Repr.Create] will parse the body and return a IO[Repr.Create]. We need to liftF because the for comprehension is type Kleisli[IO, HasXYZ, Response[IO]].
4. has has type HasDatabase, which means it has database transact method, when run convert Quill's quote into ConnectionIO[A], transact can execute it in one transaction.

If you're not fan of Macro it is very easy to switch back to doobie DSL:

 1: val CRUD = AppRoute {
 2:     case req @ POST -> Root / "joke" =>
 3:       for {
 4:         has <- Kleisli.ask[IO, HasDatabase]
 5:         joke <- Kleisli.liftF(req.as[Repr.Create])
 6:         id <- has.transact(
 7:           sql"insert into joke (text) values ${joke.text}".update.withUniqueGeneratedKeys("id")) // <- (doobie)
 8:         _ <- log.infoF(s"created joke with id $id")
 9:         resp <- Created(json"""{"id": $id}""")
10:       } yield resp
11: }

Similarly you will probably figure out how to implement a GET /joke endpoint already.

But we has some killer feature in Http4s, we can stream the list of jokes direct from DB to response body. Which means you don't actually need to read all jokes into memory, and then return it back at one go, the data of jokes can actually flow through your Http4s server without accumulating in the memory.

 1: case GET -> Root / "joke" =>
 2:   Kleisli
 3:     .ask[IO, HasDatabase]
 4:     .flatMap(
 5:       db =>
 6:         Ok(
 7:           db.transact(stream(quote {   // <- (stream)
 8:             query[Dao.Joke]
 9:           }))
10:             .map(Repr.View.from)
11:         )
12:     )

stream is provide by doobie, which returns Stream[ConnectionIO, A], when transact it we will get a Stream[IO, A], luckly Http4s response accept a Stream[IO, A] as long as we have a EntityEncoder[IO, A].

It is too straightforward to implement a GET /joke/:id:

case GET -> Root / "joke" / IntVar(id) =>
  for {
    has <- Kleisli.ask[IO, HasDatabase]
    joke <- log.infoF(s"getting joke $id") *> Kleisli.liftF(
      IO.shift(IO.contextShift(ExecutionContext.global))
    ) *> has.transact(run(quote {
      query[Dao.Joke].filter(_.id == lift(id)).take(1)
    }))
    resp <- joke match {
      case a :: Nil => Ok(a)
      case _        => NotFound(id)
    }
  } yield resp

Let's add some feature to it, for instance, if there is no joke in database, how about randomly generate some dad joke? And we like 50% of users can see random joke instead of hitting NotFound

To prepare a feature toggle in Finagle, you have to put a file in directory src/main/resources/com/twitter/toggles/configs/com.your.domain.http4sexample.json. where com.your.domain.http4sexample is your application package.

And then put in the toggle:

{
  "toggles": [
    {
      "id": "com.your.domain.http4sexample.useDadJoke",
      "description": "random generate dad joke",
      "fraction": 0.5
    }
  ]
}

It is good practice to have id naming with proper namespace too.

0.5 fraction means there will be 50% chance for the toggle to be on status.

How can we use this toggle in source code? https://github.com/jcouyang/http4s-example/blob/master/src/main/scala/com/your/domain/http4sexample/resource/toggle.scala#L9

Inject HasToggle effect

- has <- Kleisli.ask[IO, HasDatabase]
+ has <- Kleisli.ask[IO, HasDatabase with HasToggle]

Switch on the toggle

1: dadJoke =                             // <- (declare)
2:   if (has.toggleOn("com.your.domain.http4sexample.useDadJoke"))
3:     log.infoF(s"cannot find joke $id") *> dadJokeApp.flatMap(NotFound(_))
4:   else
5:     NotFound(id)
6: resp <- joke match {
7:   case a :: Nil => Ok(a)
8:   case _        => dadJoke            // <- (usage)
9: }

dadJokeApp is a HTTP effect which call another API, we will go through later.

Here is another advantage of FP over Imperative Programming, dadJoke is lazy and referential transparent, which means I can place it anywhere, and whenever I reference it will always be the same thing. While in Imperative Programming this won't be always true, i.e. when you declare a val printlog = println("log") it will execute immediately where it declared. But later on when you refer to printlog, it is not the same thing it was defined. Since the log is already print, it won't print again.

So, simply declare a dadJoke won't execute dadJokeApp to actually send out the request. We can safely put it for later usage in pattern matching

To get a random dad joke remotely, you will need a Http client that talk connected to the remote host.

Finagle Client is actually a RPC client, which means a client will bind to particular service.

Assuming we have already define a jokeClient in HasClient, a dad joke endpoint will be as simple as:

val dadJokeApp =
  Kleisli.ask[IO, HasClient].flatMapF(_.jokeClient.expect[DadJoke]("/"))

The client can be make from resource/package.scala and then inject into AppResource

js <- http.mk(cfg.jokeService)

where cfg.jokeService is uri"https://icanhazdadjoke.com"

Finagle already provide sophisticated tracing and metrics, zipkin tracing is by default enable, but it is sample rate is 0.1%, to verify it work, we could start the server with parameter

> sbt '~reStart -zipkin.initialSampleRate=1'

Sample rate 1 means 100% of trace will report to zipkin.

curl localhost:8080/random-joke

The resource maker's type is slightly tricky because it is Resource[IO, Resource[IO, AppResource]]:

def mk(implicit ctx: ContextShift[IO]): Resource[IO, Resource[IO, AppResource]] =
  for {
    cfg <- Resource.liftF(Config.all.load[IO])
    js <- http.mk(cfg.jokeService)
    db <- database.transactor
  } yield Resource.make(IO {
    new AppResource {
      val config = cfg
      val jokeClient = js
      val database = db
    }
  }) { res =>
    res.logEval
  }

Why should we have nested Resource here?

These are actually two different kinds of resource, the first level is whole server scope, all requests through this server share the same resource.

• config
• database
• HTTP client

In another word, these resources are acquired when server start, closed when server close. And there are few resources not share across server, they are acquired when request arrived, closed when response sent:

• trace
• toggle
• logger

Once we implemented all CRUD endpoints for /joke, testing these endpoints actually are very easy via ScalaCheck property based testing:

 1: property("CRUD") {
 2:   implicit val appRes = new TestAppResource              // <- (testResource)
 3:   forAll { (requestBody: joke.Repr.Create, updateBody: joke.Repr.Create) =>
 4:     when(appRes.toggleMap.apply(useDadJokeToggleName))   // <- (toggleOff)
 5:       .thenReturn(Toggle.off(useDadJokeToggleName))
 6:     createAndDelete(requestBody)                         // <- (createDelete)
 7:       .use { id =>
 8:         assertEquals(query(id).flatMap(_.as[joke.Repr.View]).unsafeRunSync().text, requestBody.text)
 9:         update(id, updateBody)                           // <- (update)
10:           .map(_ => assertEquals(query(id).flatMap(_.as[joke.Repr.View]).unsafeRunSync().text, updateBody.text))
11:       }
12:       .unsafeRunSync()                                   // <- (execute)
13:   }
14: }

To test all CRUD we just need scalacheck to randomly generate arbitrary create request body and update request body.

1. New a fake resource TestAppResource, defined in SpecHelper.scala
2. Don't forget to toggle off our fancy dad joke toggle
3. Make create and delete a resource so our test data will always clean after assertion

def createAndDelete(req: joke.Repr.Create)(implicit router: HttpApp[IO]) =
    Resource.make[IO, String](create(req))(delete)

1. Assert there will be a joke created
2. Update the joke and then query again to verify the data is updated
3. Don't hesitate to unsafeRunSync the Resource, it is OK to fail fast at runtime in test.

To package the server into a runable binary, simply:

> sbt bootstrap

To run:

> ./http4s-example

Package it to docker to ship to heroku or k8s

> docker build . -t http4s-example

The same way we can package and deploy migration scripts as well

> sbt db/bootstrap
> ./http4s-example-db-migration migrate