Netty 4 is a default now
Finagle 6.45 brings HTTP implementation based on Netty 4. It's now a default transport for both servers and clients created with Finagle. At this point, it's known that finagle-http running Netty 4 might be performing slightly worse than Netty 3 given the overhead the outdated Netty 3-based HTTP model involves. The Finagle team is aware of that and is working hard to remove the Netty 3 dependency from finagle-http hence make it faster with Netty 4.
If you're cautious about the performance degradations (roughly 15%-20% slower on our "Hello, World!" benchmark) during the upgrade, stick to Netty 3 for now (as shown below):
import com.twitter.finagle.Http
val server = Http.server.configured(Http.Netty3Impl)Default exception encoders
We decided to stop supplying the default instances of exception JSON encoders (i.e., Encode.Json[Exception]) given the amount of confusion and ambiguity they bring on the table (examples: #765, #737). The default behavior now (unless an instance of Encode is provided) is to encode exceptions to just empty payloads.
New syntax package
We're starting to decouple Endpoints from their syntax (i.e., Mapper). The fact they were coupled together caused lots of surprising compile errors in the past (especially in the Scala 2.10 times) and we're quite happy to start drawing a line between a concept and its syntax. As of this release, there are no breaking changes such that the Endpoint.apply(Mapper) is still supported (although not directly) but we're planning to start hiding things behind the io.finch.syntax namespace in the next release. See #779 for more details.
New API for path matching
We're promoting a new and more explicit API for path matching. Now there is a path method that acts as following (see #771 for more details):
path("foo")- matches a path "foo" (was"foo": Endpoint[HNil]before)path[String]- extracts a string path (wasstringbefore)
Note that the previous API (i.e., int, string, etc) is still supported and we're pending its depreciation given the successful adoption of the new API.
While the new way is definitely more verbose (see example bellow) we think it is much more explicit and clear for the reader. At some point (when we merged request readers with endpoints), symbols as int, string, etc become ambiguous (i.e., does int means "path as int" or "param as int") and are not something we'd like to see as part of 1.0 API (stable API).
val a = get("add" :: path[Int] :: path[Int]) { (a: Int, b: Int) => Ok(a + b) } // new
val b = get("bar" :: int :: int) { (a: Int, b: Int) => Ok(a + b) } // old