

Ebay launches query language - jurre
http://ql.io/

======
mjs
Interesting, another use of a SQL-like language as the query language for a
data store that's definitely not an SQL database. (YQL is another example.) I
really don't understand why ORMs always seem to want to create their an
object-based query language--SQL is just fine for querying.

~~~
politician
It's difficult to provide tooling for SQL in a way that provides a good
experience for the user. For example, providing auto-completion in a SELECT
statement is hard because attributes are specified before the tables which
contain them are declared, leading to a-more-annoying-than-it-should-be
editing experience.

------
itmag
Interesting. Isn't this the metalinguistic paradigm in action? Ie instead of
creating a library/API you create a whole new Domain-Specific Language.

Thoughts on this? Is there room for innovation in APIs via DSLs?

~~~
itmag
It would be cool if there was some kind of meta-DSL which allowed you to
create your own DSL. That way, more developers could go that route without
having to learn all the intricacies of compiler theory and stuff like that.

I am imagining DSLs being useful both on the server side and the client side.
For the former, imagine sending off a single query instead of doing a bunch of
different API calls. For the latter, well, JQuery is an existing example of a
popular client-side DSL (technically it's not, but it feels that way).

~~~
gcr
It's called Lisp. I hate to be Yet Another Hacker News Lisp Punditparrot, but
it's true.

For example, take a look at how easy it is to implement BrainF inside Racket,
a lisp focused on language experimentation.
<http://hashcollision.org/brainfudge/> I bet you could walk through these
steps in maybe half an hour with little to no prior experience.

~~~
mythz
eh easy? that's one of the longest pages on the Internet! Here's a BrainF
interpreter in 1 line of Python:
<http://www.cs.princeton.edu/~ynaamad/misc/bf.htm>

Granted it expands to more than one line, but I'm not seeing that as a good
example of lisp's superiority.

~~~
p4bl0
It's absolutely not the same thing : the Racket example is not a Brainfuck
interpreter, it's an actual DSL _inside_ Racket, which benefits from it's
whole infrastructure (JIT compilation etc.). It's not the Racket language
running a BF interpreter. It's the BF language running.

------
buro9
Anyone who implements this might want to bear in mind that you will have
created a very chatty backend based on JSON calls.

It should be fairly obvious that you're quite likely to now have pain points
in serialising and deserialising that much JSON.

It seems to me that you now have 2 choices:

1) You forget this approach and instead perform REST composition and
aggregation by adding a datastore in the composition/aggregation service to
reduce the number of calls to the back end.

2) You ditch the internal REST services and change to using protocol buffers
or something else to remove the JSON bottle neck internally.

Either of which will make ql.io redundent.

ql.io appears to be trying to solve REST as the language of enterprise
services, without using a service bus or BPEL to aid with composition or
aggregation.

I agree there is a problem space here, and whilst I have an immense amount of
respect for Subbu (worked on ql.io, authored REST book) I'm unconvinced that
this approach is the solution to the problem.

------
mjs
Ah, looks like this is the library Subbu Allamaraju refers to at
<http://www.subbu.org/blog/2011/11/apis-are-a-pain--the> aim of ql.io is to
alleviate the challenges of "aggregation, parallelization, and orchestration
of forks and joins." (i.e. in practice, "consistent RESTful APIs don’t matter
as much as we think," nice though they may be.)

------
kilovoltaire
I've been thinking lately that certain APIs would benefit from two distinct
'entry points':

1\. a nice, object-oriented hierarchical RESTful interface for standard
queries and getting started e.g. /api/user/12345/friends/

2\. a sql-esque query language interface for arbitrary, complicated requests
e.g. /api/?q=select id from users where name="Joe"

It looks like ql.io could be a good way to provide the latter.

~~~
s3u
Right. One of ql.io's goals is to enable (b) but on a tier between clients and
servers.

------
gislan
Why, oh why did they put "select" before "from"? It makes auto complettion so
much harder.

~~~
arb99
easier to remember that format, other sql formats are same order...

~~~
s3u
Exactly. We tried to stay close to the SQL syntax to a large extent although
there is no relational storage underneath.

------
tlianza
This looks a lot like OData... strange that they don't mention it when they
compare themselves to other querying technologies on the 'about' page.

<http://www.odata.org/>

~~~
s3u
OData specifies a resource model, resource metadata and URI naming conventions
for HTTP APIs. The query formats in OData are part of the producer-implemented
APIs as queries happens at the origin. ql.io is a layer above such APIs, and
generally operates across several such APIs.

------
charliesome
Site's down for me

~~~
jurre
For me too now, theres some info on their github page: <https://github.com/ql-
io/ql.io>

~~~
charliesome
Ah, thanks for the github link. It looks like an interesting project although
I'm not sure what it brings over a more 'traditional' approach to API
consumption

~~~
jurre
What I got from their website earlier is that it's meant to reduce the number
of API requests by bundling multiple datarequests, giving you better
performance.

------
simonbrown
Having the "fork me" button above the scrollbar (at least in Chrome on
Windows) looks pretty ugly.

~~~
s3u
Thanks for the "hint". Checking.

------
abava
Yahoo Pipe ?

