Ruby Power Meet up 2015 has recently finished. One of the main speakers of the conference was Yury Kaliada, co-founder of Rubyroid Labs. He spoke about Apache Thrift and ways to use it on order to combine a few languages in one project. Find the main takeaways from his speech in our article!
What the problem is?
It is not a common practice when developers are using a few languages in their project. But sometimes they really need multiple languages to make the application better. There can be a few reasons, including:
- Language specific features (Java or Erlang for multithreading, .Net for Microsoft documents generation, etc)
- Performance and stability (Languages with static typing tend to be more stable and can show you part of the error before you run the application)
- Development speed (Languages with dynamic typing speed up the development but have performance issues)
- Or just in case a developer is bored 🙂
In case a developer want to use multiple features from the list above it is a high chance that he has to use multiple languages for that. In that case he comes up with a major problem: the tool for that should be highly reliable and provide easy integration. There are pretty much alternatives on the market thus the full comparison of them might have enough information for a single book! Also it is a good idea to take an alternative which is familiar for most of the developers to use it as a base point. That’s why Apache Thrift with REST API will have the most sense.
REST API vs Apache Thrift
Some developers tend to use REST API for that. Generally, it is a good approach, but sometimes it can be too slow. It mainly uses HTTP to transfer data and does not suit for binary data transfer. Sure high quality developer can fix that with third party libraries but the main question is: may be there is already a better tool which was designed for the application needs?
|Advantages of REST API:||Disadvantages of REST API:|
|1. Easy to setup||1. Serialization overhead|
|2. Cross-platform||2. No endpoint validation|
Taking into consideration all these problems, Apache Thrift tries to be a silver bullet. Well Apache Thrift uses binary protocol to transfer data and that is vital for large applications. Also the bindings (integration code) might be generated for multiple languages. All what developer should do is write the logic. Unfortunately we are leaving in not a perfect world and Apache Thrift requires a developer to acquire basic knowledge and finish some preliminary work.
|Advantages of Apache Thrift:||Disadvantages of Apache Thrift:|
|1. Low serialization overhead||1. Takes some time to setup|
|2. Endpoint validation|
|3. Generates bindings|
How to install Apache Thrift?
- Create .thrift file
- Thrift –gen <language> <tfile>
- Include bindings
- You are ready to go
Thrift file example
Here you can check the Thrift IDL (interface definition language). It is very C-like and it is an advantage because of simplicity and readability.
Apache Thift tries to be as much multipurpose as possible. That’s why the Apache team decided to support only basic types and three types of collections. They all are easily mapped over 99% of languages we have in the modern IT world. Here is the supported list:
- i16, i32, i64
- list <t1>
- set <t1>
- map <t1,t2>
Here is an example of a endpoint definition which has multiple arguments. Look carefully at the image below. The arguments are explicitly numbered and it looks pretty strange at first glance. But for sure it was done intentionally. The main idea is backward compatibility. Just imagine that a mobile application uses Apache Thrift and major part of the users did not update the application to the latest version. As a result part of the clients will use outdated endpoints. Apache Thrift will do all the hard work for us and map the arguments between the endpoint versions leveraging these numbers.
Once we feel comfortable with IDL and .thrift file is finished we are ready to generate bindings. Only one command is needed:
thrift -r –gen ruby messenger.thrift
As a result we get next file structure:
It look pretty straight. Constants and types are empty as far as we did not define any of them in our thrift file. Let’s take a look at messenger.rb where the service is defined. The biggest advantage here is readability. Generated code is not obfuscated or minified and it will not take a long time to figure out an error.
Once the generated bindings are clear we are ready to run server. It takes only ~10 LOC to create server and run it. A developer should notice the main advantage of the code below. It looks like a LEGO kit. You take one peace and combine with another one. That approach gives high flexibility. Apache Thrift has pretty much ready to use processors transports and servers. Developer should only check the application needs and choose the proper combination. In case application needs are very specific – it is always possible to write a custom versions of each part.
Finally we are ready to launch a client which looks pretty much like server.
Feel free to use the code above and have a good luck with your multi-language projects!
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?
Thank you for the article! Would you have any suggestions/tips/how-tos on running Thrift on a PaaS like Heroku?
I would suggest to run Thrift on an IaaS instead since it is really important to have deep control when you are building such complex systems. Using PaaS you will hit their limitations very quickly