Drill is a HTTP load testing application written in Rust inspired by Ansible syntax


drill


I'm a daily user of [Tmux](https://github.com/tmux/tmux) as my favorite
terminal multiplexer. One day, talking to
[Jorge](https://github.com/Morantron), he impressed me with a new hint
picker in the terminal. He was able to pick paths, sha's and other
interesting stuff with few keystrokes. My reaction was priceless.

Jorge did an extraordinary job, building all necessary pieces in Bash to
achieve the text picker behaviour. He only deserves my gratitude for all the
time I have been using
[tmux-fingers](https://github.com/Morantron/tmux-fingers).

During a [Fosdem](https://fosdem.org/) conf, we had the idea to rewrite it to
another language. He had these thoughts many times ago but it was hard to start
from scratch. So, we decided to start playing with Node.js and
[react-blessed](https://github.com/Yomguithereal/react-blessed), but we
detected some unacceptable latency when the program booted. We didn't
investigate much about this latency.

During those days another alternative appeared, called
[tmux-picker](https://github.com/RTBHOUSE/tmux-picker), implemented in python
and reusing many parts from
[tmux-fingers](https://github.com/Morantron/tmux-fingers). It was nice, because
it was fast and added original terminal color support.

I was curious to know if this was possible to be written in
[Rust](https://www.rust-lang.org/), and soon I realized that was something
doable. The ability to implement tests for all critic parts of the application
give you a great confidence about it. On the other hand, Rust has an awesome
community that lets you achieve this kind of project in a short period of time.

## Demo
[![demo](https://asciinema.org/a/232775.png?ts=1)](https://asciinema.org/a/232775?autoplay=1)


A lightning fast version of tmux-fingers written in Rust, copy/pasting tmux like vimium/vimperator


tmux-thumbs


I remember it was about two months ago when I was talking with Eduardo
Lanchares about the best stack for the next webapp. Sometimes you are at work
and you are stuck with the current set-up of frameworks and tools that are
quite difficult to change or refactor. This forces you to always work with the
same mentality not allowing you to test new approaches to solve problems.

Following our desire to learn new stuff to make our life easier, we wanted to
experiment with new technology to build a side project with a complete new
stack that fits better with the app requirements.

In that same week, a friend of mine was talking about a bug that was affecting
him in the web client of Transmission. This [bug](https://trac.transmissionbt.com/ticket/5857)
was affecting more people because we found an open bug report in the tracker
that was 2 years old. We decided to check the source code and try to fix it
because we thought that would be a piece of cake. But a few hours later we
discovered that was not as easy as we expected and at some point we gave up.

With all these things in mind we had the perfect scenario and excuse to start
playing with a new side project. We decided to start building a new interface
from scratch to understand new patterns, new approaches and discover what would
be the next challenges for the _ultimate interface_.

## Our experimental stack

Reviewing all of the features in the current Transmission web client, the stack
we chose was React for the user interface, Mobx for the state management and
CSS modules for all the stuff related with the application styles, with a new
build process managed by Webpack.

On the other hand, and with the above stack in mind, we decided to use some
best practices for the long term quality of this project. Some of these were
things like a strict set of Eslint rules, unit tests, UI tests and
internationalization.

With this decision we wanted to achieve a more reliable interface, better
performance, security and correctness. In conclusion a better way to maintain
this web application.

## Demo
![demo](demo.gif)

## Other

With Edu, we presented this experimental project on the BarcelonaJS. Those are
the slides: [Presentation in BarcelonaJS](https://docs.google.com/presentation/d/1cYbyC2Qkf85SQm4Ceq7e9TzXgaiJwMJ_VYilGn-_960/edit?usp=sharing)


React Transmission is an ongoing reimplementation of Transmission web interface.

react-transmission


I started this project as a side project to learn Rust. I was searching a
combination of different technologies to play with. I was looking for some
ideas of projects where **network communication, concurrency and file parsing**
were essential parts of the project.

I used some load testing application in the past like *JMeter*. Although they are
so powerful and great, at some point it started to be complicated and
cumbersome to setup a test plan. For this reason a lightweight
[Rust](https://www.rust-lang.org/) application to run a load testing plan of
your web application looked a good side project to create Drill from bottom up.

The project was really influenced by this new trend of having a configuration
Yaml file to code a set of actions. At that time my reference was the syntax of
[Ansible](https://www.ansible.com/).

The project started with a small set of features, but for years we have been
keep adding more and more set of nice things. Right now you can do awesome
things like choose the number of requests, choose the concurrency, dynamic
headers, load CSV, cookie support and much more.

If you want to play with it, you have it available as a binary in
[crates.io](https://crates.io/crates/drill).

Really happy of this project that helped me to learn Rust and all the ecosystem
around it. Also, I want to say thanks to all developers that helped to improved
it. 🙌

## Demo
[![demo](https://asciinema.org/a/164615.png?ts=1)](https://asciinema.org/a/164615?autoplay=1)


~ferran.basora

Demo