Separation of Concerns with Finagle

The Separation of Concerns (SoC) pattern is one of those software architectural choices that everyone is helpful. It increases clarity, shortens the amount of code in the working context, and minimizes the chance of side effects. For example, two concerns that shouldn’t require entanglement: updating data and cache invalidation. Both are related, but one is concerned about business logic and database access, while the other deals with the cache servers. Finagle’s generated FutureIface can be used to keep these two separate. Continue reading

Transitioning C# to Scala Using Thrift

ScalaA 30 minute presentation I made on Sept 19th in a Scala-Toronto meetup. The slides introduce Apache Thrift and the additional features offered by Twitter’s Finagle stack.

The overall theme is presenting the lessons learnt while using of the cross-language RPC capabilities of Thrift to transition a Microsoft .Net C# workplace to Scala.

Scala-Toronto meetup

Slides: Transitioning C# To Scala Using Thrift.pdf

The presentation’s slides are from a technical prospective; a co-worker has an excellent blog elucidating the motivation, social effect, and final outcome of the company’s decision to choose Scala. It is well worth a read.

Tracking Clients with Finagle

In a Service Oriented Architecture, a service may be used by many different clients – each with with different usage patterns and performance profiles. Behind a corporate firewall, without each client authenticating itself to our server, how can monitor a specific client if we can’t identify their requests?

One way would be to track each client’s IP, but servers change and it may be impossible to coordinate across teams. Another would way is to push the logging and monitoring responsibility to each and every client. However the easiest way would be to watermark each thrift request with client information, but does the standard thrift protocol allow it? Continue reading

Thrift Client Side Caching to Speed Up Unit Tests

One of the largest headaches associated with network system architecture is abstracting away the network. External resources are always slower and more disjoint than working locally. While there are various caching techniques, few are suitable for use in a development environment.

Client-side unit tests usually only have two options: executing calls against a deployed server thereby struggling against long waits per testing iteration, or having all calls tediously mocked out.

An alternative approach available within Finagle: a pre-populated query cache on the client side. Continue reading

Finagle Query Cache with Guava

For many data services, any easy way to reduce database load is to cache calls to semi-static data (ie: append-only, or refreshed only on a set schedule), and very recent calls due to backward user navigation. Not all methods and data are suitable for caching, so any implementation will require the ability to be selective.

Using Finagle’s Filters we can configure our caching in a central place, leaving individual method implementations clean of the concern. Continue reading

Multiplexed Services in Finagle

Apache Thrift is a pretty good RPC library.  Methods compose a service, and the service is hosted on a raw TCP port. Even a large implementation with a hundred methods will perform effortlessly, but for organizational purposes you’ll want to group calls together into separate services. The standard thrift protocols require that each service retain exclusive use to its own TCP port, creating a firewall maintenance nightmare.

Enter service multiplexing: the ability to run all services on a single port. Continue reading