ripe-atlas is now usable…
Background
A long time ago, I got a RIPE Atlas probe from a friend of mine — who does not know Stéphane Bortzmeyer?. For those who don’t know, these probes creates a big friendly botnet that enables all users — including you, whether you have one or not — to create “measurements” on the global Internet.
Measurements are used today to (guess what) measure things like DNS queries, network latencies and more. Having a probe enables you to participate by submitting your own network data. The more probes there are, the better. It has been frequently used on the past to find out about DNS censorship like here, here or here.
How does it work? The probes have a set of builtin measurements that get sent regularely to the RIPE servers and there is an API available to make queries out of these probes. There is of course an official tool available but it is in Python. While I could just use it, I do not like Python.
Various tools are available in different languages as well here.
As a Golang fan, I’ve tried to use these and was never satisfied. Either the CLI sucks or the tool had too many dependencies or something else. So you can guess, I had to write one myself. That was also an excuse to play a bit more with Go as a language :)
And today, I released version 0.21 of my so called ripe-atlas tool. After (way too many) commits, changes and test-by-errors, it is now usable.
Of course it is still lacking many features — mainly related to output formatting — but both the Go API and the CLI tool are usable. In the coming months, I plan to add templating support to the CLI tool (atlas) whiled the API itself should be relatively stable.
The API
The API itself is v2-only; while I was beginning to write ripe-atlas, they moved from API v1 to API v2 and I decided to only implement v2, v1 being officially deprecated. I tried to play with Swagger to save myself some lines of code (LOC) as the documentation is generated by it but while it is fine when you are designing an API, when you have re-create all the stuff yourself, it is cumbersome.
I started using one of these REST libraries (after testing a few, I settled on the Sendgrid one) but in the end, after writing the HTTP proxy code, I ended up using on the standard HTTP client which is fine for my usage.
The API itself is very rich and has a lot of parameters; that tends to complicate both the API usage and its configuration. It also make the atlas tool complicated as well, I’m sure there are improvements to be made to its UI.
atlas CLI tool
I tried to implement as many unit tests as possible but I always gets behind. TDD (Test-Driven Development) is a fine concept and I try to use it as much as possible but when I’m writing I generally do not know exactly how I want to shape things which means I would spend way more time thinking about the tests and less on writing it. I am ok with the philosophy but I can’t seem to be able to follow it stricly. Oh well.
One of the way I always do when using/defining an API is to have a way to test these things but less formally. The atlas CLI (Command-Line Interface) is such a way. In fact, the first goal of projects like this one is to have a nice CLI tool. That way, I was able to experiment and play with nice Go modules such as cli and TOML.
The code
Everything is available on my github.com account here. As it is a publicly available Go program, the documentation is automatically generated on Godoc. As you can see, it is far from complete. I need to add many comments to structures and function calls throughout the program.
Most of the development is done on the develop branch as I’m trying to use the Git flow workflow to manage development and release management.
As usual, all comments, issues and pull request are welcome, enjoy!