Announcing ql.io

I am super-excited for to announce the public release of ql.io today.

ql.io is a declarative, evented, data-retrieval and aggregation gateway for HTTP APIs. Simply put, this is our answer to the pain points that I recently described in my APIs are a Pain post.

Here are some key points that I want to highlight about ql.io.

Built on node.js

We chose node.js for its evented programming model and a dynamic language. This choice has kept us productive in the last 5-6 months as we built the core from ground up. I would love to share more details about our experience once I have some concrete numbers to show.

A SQL and JSON based DSL

ql.io uses a SQL and JSON based DSL to write scripts to make HTTP requests. This idea has been tried before, most notably by YQL, and in a slightly different context by unQL. But ql.io pushes the envelope further by cutting down the coding costs of writing fork-join code. See the Language Overview to see how.

Procedural style

ql.io scripts are procedural looking, but the underlying engine executes them in the best order possible based on a dependency analysis. Consider the script below.

a = select a from A;
b = select b from B;
c = select c from C where cparam = "{a.someparam}";
d = select d from D where dparam1 = "{c.someparam}" and dparam2 = "{b.param}";

Each statement is scheduled for execution when all its dependencies have been met. This leads to significant reduction in number of lines of code. One of the first apps I built condensed a 300-line Java app into a 10 lines of script.

Interoperability

My interest in interoperability started with my work at Yahoo! with Bruno. The challenge was how to ensure that HTTP APIs built by decentralized teams interoperate. The first attempt at this problem was a stick that says "you shall conform to such and such rules, or else …" But this is not a viable idea. The second attempt involved placing some minimal constraints such as links and identifiers on each API to make them interoperable. While it sounded like a good idea at the time, it has the same problem as the stick.

The challenge with interoperability is how to make the API Web interoperable without introducing new agreements (or protocols) between them. It turns out that we already agreed on some basic protocols such as TCP, HTTP, URIs, XML, JSON and so on on the Web. What if we turn the problem of interoperability from new protocols to software? That is what we tried in ql.io. We made ql.io as a platform that enables interoperability between decentralized HTTP APIs.

ql.io is capable of interacting with any HTTP speaking entity. You got SOAP APIs? Fine! ql.io can speak to it, and mix the response with responses from other APIs that are more conformant to HTTP. Try this query to find for yourself.

See Announcing ql.io for the complete announcement.