The Twitter Developer Blog

Your source for new features, best practices and real-world use of the Twitter Platform.

Results from Developer for: March 2012

Twemproxy: A fast, light-weight proxy for memcached

Today, we’re open sourcing Twemproxy, a fast, light-weight proxy for the memcached protocol. Twemproxy was primarily developed to reduce open connections to our cache servers. At Twitter, we have thousands of front-end application servers, and we run multiple Unicorn instances on each one. Each instance establishes at least one connection to every cache server.


Cassie: A Scala client for Cassandra

I’m happy to announce today that we’re releasing our Cassandra client to the open source world:

Cassie is a Finagle and Scala-based client originally based on Coda Hale’s library.


Community Developer Teatimes coming to Toronto, Dublin, and Amsterdam

Over the past couple of months, we’ve been able to make it out to some great cities - but we won’t be able to make it to all of them right away. Luckily, a few members from the Twitter developer community have organized Teatime events in their respective cities - and if you’re near one of those cities, we’d love for you to join them. The organizers will give a presentation on the Twitter APIs followed by local companies sharing experiences and best practices for integrating with the platform. Twitter platform team members will be participating remotely during the Q&A session.


Turning on gzip for this week

As previously announced, we are planning on turning on gzip compression for this week. A gzipped stream offers a huge bandwidth reduction over an uncompressed stream, so if you’re consuming streaming data from, we encourage you to support this feature.

For information on how to request a compressed stream, and for a workaround to an issue which Java clients may experience, please consult the gzip streams documentation.


Making API responses match the request Content-Type

Hello Developers!

We’d like to change the content type of error responses to API requests. For anyone unfamiliar with the way things currently work, the current response body for 404, 500, and 503 errors is an HTML-formatted web page, which is a pain point for those of you expecting an XML or JSON response. We want to bring that more in line with the rest of the API, and will be making API error responses match the requested data format where possible.