Copycopter's client: so fast


We recently launched our latest product to great critical acclaim. We’re happy to see people climbing aboard the Copycopter, and feedback has been largely positive.

However, one question we’ve had to field a few times is, “how will Copycopter affect the performance of my application?” The answer is a good one: it won’t. However, that answer may seem too good to be true to some folks, so let’s find out how Copycopter manages to stay out of your application’s way.


One of Copycopter’s nicer features is that the Ruby client is deeply integrated into the Rails stack the second you install it. This is made possible by the excellent Rails I18n API. We hook in our own I18n backend so that whenever Rails looks for a string, we use the text you’ve set up on Copycopter. This all happens in copycopter_client’s I18nBackend class. If you read quickly through that class, you’ll see that fetching or storing copy doesn’t make a request to the Copycopter server; it looks for content in the hash-like sync object.

def lookup(locale, key, scope = [], options = {})
  parts = I18n.normalize_keys(locale, key, scope, options[:separator])
  key_with_locale = parts.join('.')
  content = sync[key_with_locale] || super
  sync[key_with_locale] = "" if content.nil?

Behind the scenes

The client’s performance is acheived by using a background thread. When your Rails application starts up, the client spins up a thread in the Sync class.

    until @stop
      logger.flush if logger.respond_to?(:flush)

Every five minutes, the background thread synchronizes with the Copycopter server. It uses mutexes to make sure it isn’t updating copy while the application is using it. However, the mutex is only locked when already downloaded copy is being swapped in, so the main thread won’t be waiting for a lock to release.

def download do |downloaded_blurbs|
    downloaded_blurbs.reject! { |key, value| value == "" }
    lock { @blurbs = downloaded_blurbs }
rescue ConnectionError => error

HTTP friendly

We also don’t want to waste any bandwidth or cycles by repeatedly downloading unchanged copy. The Client class is responsible for actually talking to the Copycopter server, and it speaks fluent HTTP.

def download
  connect do |http|
    request =
    request['If-None-Match'] = @etag
    response = http.request(request)
    if check(response)
      log("Downloaded translations")
      yield JSON.parse(response.body)
      log("No new translations")
    @etag = response['ETag']

Each running client tracks the latest ETag when it downloads copy, so most requests simply return a 304 Not Modified response without sending any copy data.

when Net::HTTPNotModified


It should be mentioned that this passive behavior is only used in production environments. During development and on a staging server, we found a five minute delay between copy updates to be unacceptable. During development, we wrap each request using a little piece of Rack middleware:

def call(env)
  response =

Although this could potentially add a slight delay to local requests, we found that the faster feedback was worth the tradeoff, and the smart HTTP handling, caching, and timeouts ensure that developing still feels snappy.

Putting it all together

By integrating with I18n, using a background thread, and using the HTTP protocol to our advantage, we achieve a number of performance and stability benefits:

  • Slow copy downloads don’t mean slow applications
  • Server errors don’t mean application errors
  • Lots of application traffic doesn’t mean many Copycopter requests
  • Up-to-date copy doesn’t cost much in terms of bandwidth
  • Rails uses the I18n stack, so Rails engines and plugins support Copycopter by default

If you haven’t given Copycopter a try yet, don’t let apprehensions about performance stop you. Check out the code, install the client, and see for yourself.

Get to the choppa!