The key to high availability is redundancy; it follows that if uptime matters, Finagle needs to be deployed to multiple servers. This article walks through both the basic multi-host configuration using finagle-core, as well as a more robust deployment scenario utilizing the finagle-serversets module. Continue reading
When using Thrift, Finagle Filters on the client inherit from SimpleFilter[ThriftClientRequest, Array[Byte]], while on the server they must inherit from SimpleFilter[Array[Byte], Array[Byte]]. In this article, we will demonstrate one approach to creating a dual-function filter without repeating code. Continue reading
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
A 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.
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.
This is an obscure issue, with an easy workaround, but no obvious solution.
You chose the Finagle RPC stack because you have old and dusty C# applications mixed in with your Scala. It’s only inevitable that one day you will connect a Finagle client to your C# server, and it won’t work. Continue reading
Long running queries are very taxing on a database. But caching idempotent queries may not always be a suitable solution.
What happens if queries run for N-seconds, but users expect to see new changes immediately?
What happens if queries return large datasets that won’t all fit into memory?
There is a middle ground. Continue reading
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
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
In a system of async service calls, sometimes the most indispensible debugging tool is knowing what and when network traffic is occurring. Unfortunately for developers Finagle’s default protocol is binary, which while undecipherable, it can be transformed into something a lot more useful. Continue reading
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