Thrift API Versioning with .Net

SOA Versioning

Service Oriented Architectures (SOA) expose a set of services using a platform independent method. With hosting any service you inevitably require changes, which are not backwards compatible. When deploying a new version with changes which are not backwards compatible, consumers will still be referencing the old version and the old version must continue to work.

The most common solution across SOA frameworks seems to be to not make breaking changes. .Net SOA frameworks in particular tend to have poor support for versioning; classic web services (services ending with .asmx) and more recent WCF services, let us define our interface as a list of c# methods and all the heavy lifting is handled transparently. Unfortunately, there is no method of defining previously supported methods. There is only 1 set of methods: the most recent version.

In this post I am investigating how versioning is supported with Thrift. How to create a Thrift Service is covered in a previous post.

Does thrift support versioning?

Thrift does not support versioning directly, but there are implementation patterns which can be used to support multiple versions. There are two patterns:

  1. Hosting multiple sites
  2. Two Thrift interfaces are defined.
    1. An interface of the current version. New clients use this.
    2. An interface with ALL supported methods. The server uses this.

Hosting multiple sites

Previous versions of services can be supported by simply maintaining older versions of the code and hosting it on separate URL’s for an HTTP service or separate IPs/Ports for a TCP service. The downside of this is that you’re maintaining twice the code; even with optimal re-factoring, you are still maintaining double the number of methods/entry-points into your system.

Two Thrift interfaces are defined

Using this method, a current version is published for new clients, while the server implements the current version as well as functionality from previous versions. This can best be demonstrated by example:


// current.thrift
service CurrentService {
  bool fooEx(1:i32 num),
  bool bar()
}

// allsupportedmethods.thrift
include "current.thrift"

service AllSupportedMethodsService extends current.CurrentService {
  bool foo()
}

By implementing the AllSupportedMethodsService interface, a service can support both the new publicly exposed service and the legacy methods as well.

Soure Code: Git Hub

Final Thoughts

Thrift provides a straight forward programmatic way of implementing multiple versions. Microsoft libraries could get a similar level of versioning control by introducing a LegacyMethodAttribute or DoNotExposeInWsdlAttribute class. These attributes would hide the method signature from the public WSDL od Restful api allowing service creators to support old methods, without exposing them to newer clients.

Advertisements
This entry was posted in .Net, Thrift and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s