I’m happy to announce that we’ve shipped version 0.1 of Taxi — which is a huge part of what powers Vyne’s integration engine.

Taxi is a DSL for describing API’s — specifically the operations they perform, and the models they return. It has a compiler for validation of models, and a powerful generation tools — for generating Taxi from source, and generating source from taxi.

The source is here, and the docs are here. (including a nice Getting Started guide)

Taxi is designed with readability in mind — Taxi documents are really easy to understand. And, although most Taxi code will be generated, it’s quite easy (and natural) to craft a Taxi document by hand.

It’s also designed to be extensible. Different teams will consume data from API’s in different ways — Taxi supports this by allowing consumers to mix in their own annotations or refinements at generation time.

Type extensions and annotations power better tooling

Services can describe not just how to call them, but what functionality they provide, and what constraints must be satisfied to call them.

We don’t even have a proper website yet.

How Taxi powers Vyne

Vyne is a tool for automating integration between services. It uses metadata published by services to understand what functionality they can provide, and how to interact with them.

To facilitate this, we needed a language that could express this information for Vyne to read — Swagger lacked the constructs we needed.

Also, we wanted something that was readable — there’s a lot of metadata to consume, and grokking through lengthy RAML documents is pretty unappealing.

So, we built Taxi.

Internally, all metadata about services is mapped using Taxi. (Note, Vyne can consume other document types, like Swagger and RAML, however these are converted to Taxi). This model is fed into our integration engine to build integrations on demand.

Prior art & Roadmap

Taxi takes heavy inspiration from Swagger and RAML, and intends to grow to become a superset of the features supported by those languages (and there’s already support for converting Swagger to Taxi).

However, as a dedicated DSL, Taxi is much more readable than either Swagger or RAML. Also, Taxi isn’t coupled to HTTP / RESTful API’s. We’re starting there, but plan on expanding to supporting streaming based API’s from MQ’s or Websocket APIs, which are rapidly becoming first-class citizens in modern applications.

What’s been shipped today is very much a 0.1 release. Taxi is used heavily within Vyne, but as a standalone tool, it’s still in its infancy. However, we’re releasing this early, to try and build discipline around shipping early.

Our generator tooling is built to provide a framework for others to extend upon. The tooling for both generating Taxi from sources, and for generating source from Taxi is built with plugins and extensibility in mind. We’ve shipped generators for going to-and-from Kotlin — but the API’s make adding other languages simple — in fact the entire Kotlin generator only took a morning to build.

There’s an API for consuming annotations when generating code — although we haven’t shipped any public facing consumers of this yet, but JPA annotation wrappers will be coming shortly.

In addition to building out our own generators, we’ll shortly be launching a hub for sharing of extensions, to encourage a developer ecosystem to build around Taxi.

Finally, there’s a tonne of documentation that’s been written on using Taxi.

In the upcoming releases, we’ll be focussing on improving developer usability of the Taxi tooling, adding support for additional languages, and further expanding the docs and use cases.