8 ms·
Ebay launches query language
- charliesome 15y agoSite's down for me
- jurre 15y agoFor me too now, theres some info on their github page: https://github.com/ql-io/ql.io https://github.com/ql-io/ql.io
- charliesome 15y agoAh, 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 15y agoWhat 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.
- simonw 15y agoAt first glance, it looks a bit like a host-your-own alternative to Yahoo!'s YQL, written in Node.js
- mjs 15y agoAh, looks like this is the library Subbu Allamaraju refers to at http://www.subbu.org/blog/2011/11/apis-are-a-pain--the 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.)
- mjs 15y agoInteresting, 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 15y agoIt'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.
- deleted 15y ago[deleted]
- itmag 15y agoInteresting. 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 15y agoIt 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 15y agoIt'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/ http://hashcollision.org/brainfudge/ I bet you could walk through these steps in maybe half an hour with little to no prior experience.
- itmag 15y agoNice. Is it possible to cross-compile it to other languages?
- gcr 15y agoI... don't think so. Not in the way you're thinking of, anyway. In this BrainF example, your language "compiles" (translates, really) to Racket expressions; then, the Racket VM "compiles" it to Racket bytecode just before running it. For something as simple as BrainF, it's not hard to write your own translator. Just replace every [ with while (* ptr) {, replace + with (* ptr)++; replace < with ptr--; and so on. Then it's essentially a BrainF-to-C translator. It's not so simple for racket in the general case. Danny Yoo is working on "Whalesong", a javascript interpreter that interprets racket bytecode so you can run racket in your web browser. http://hashcollision.org/whalesong/ http://hashcollision.org/whalesong/ It's still not a Racket->Javascript translator though. I'm not aware of similar projects for other languages. (Edit: formatting ate my asterisks)
- gislan 15y agoWhy, oh why did they put "select" before "from"? It makes auto complettion so much harder.
- simonbrown 15y agoHaving the "fork me" button above the scrollbar (at least in Chrome on Windows) looks pretty ugly.
- s3u 15y agoThanks for the "hint". Checking.
- kilovoltaire 15y agoI'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 15y agoRight. One of ql.io's goals is to enable (b) but on a tier between clients and servers.
- tlianza 15y agoThis 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/ http://www.odata.org/
- s3u 15y agoOData 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.
- buro9 15y agoAnyone 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.
- abava 15y agoYahoo Pipe ?