EBay lanceert de 'web query language' Ql.io

Developers bij eBay hebben een nieuwe programmeertaal ontwikkeld die het aantal api requests moet reduceren door meerdere dataverzoeken te bundelen. Door de taal, Ql.io, moeten websites beter kunnen presteren.

Ql.io is ontwikkeld door eBay. De makers stellen dat met de nieuwe programmeertaal er minder code nodig is om meerdere api requests tegelijkertijd te versturen. Hierdoor zou er minder bandbreedte verbruikt worden en de latency verlaagd worden. De syntax van Ql.io lijkt op de notatie van sql-query's terwijl als datastructuur json wordt aangehouden.

Subbu Allamaraju, ontwikkelaar bij eBay en verantwoordelijk voor Ql.io, meldt op zijn blog dat het schrijven van code om data via api's op te vragen in zijn ogen een nodeloos tijdrovend en complex proces is. Dit wordt mede veroorzaakt doordat een programmeur afzonderlijke, al dan niet gestandaardiseerde, api's moet aanspreken. Door Ql.io toe te passen, zou deze complexiteit voor een webontwikkelaar verminderd kunnen worden, zo stelt Allamaraju.

Om Ql.io te kunnen gebruiken, moet een webserver zijn uitgerust met de node.js javascript-interpreter. De code van de nieuwe programmeertaal is beschikbaar op GitHub en is voorzien van een Apache License 2.0.

Reacties (31)

[seba]

Wat is het verschil dan met linked data & sparql? Konden ze niet beter op die bestaande standaarden verder bouwen.

[Verwijderd]

SparQL is de query taal voor het Semantic Web / RDF (het proberen alle data op internet te annoteren en doorzoekbaar te maken). De Web Query Language (QI.io) van eBay is in feite een web-api abstractie laag (een op node.js gebaseerde middle tier) waardoor je met een relatief eenvoudige query dezelfde informatie op kan vragen die je anders zelf moet schrijven met behulp van diverse custom API calls (en de bijbehorende honderden regels code).

Vaak zijn web API's zo opgezet dat ze één specifieke set data uitspugen, en geoptimaliseerd zijn voor dat specifieke doel. Neem bijvoorbeeld de Flickr API. Daar heb je een API die kan alle foto albums van een gebruiker geven. Om alle foto's in een bepaald album op de te vragen moet je daarna een tweede API's aanroepen met het ID van het foto album waar je meer van wil zien. Om daarna van elke foto de detail informatie op te vragen moet je voor iedere foto weer een andere API aanroepen om detail informatie op te vragen. Dat zijn dus een berg API calls die voor nogal wat overhead kunnen zorgen in je applicatie, en nogal wat custom code vereissen in je applicatie. Met de Web Query Language is het mogelijk om een (op node.js gebaseerde) middle tier te installeren op een server die in feite API abstractie toepast. Daardoor is het mogelijk om een query af te vuren op de middle tier waarmee je dus vergelijkbare vragen kan stellen als een een normale SQL query kan op een relationele database, maar nu dus over web API's in de middle tier een query op te stellen over diverse api's, en het resultaat te exposen als een custom api.

De insteek is ook -volgens mij met name- zo dat de hostende partij (eBay, Flickr, Google, etcetera) de middle tier zal hosten. Doordat de abstractie op hun lokale netwerk plaatsvind, kunnen de diverse API calls veel sneller en efficiënter worden uitgevoerd dan wanneer ze allemaal vanaf een externe website / applicatie worden uitgevoerd (via internet, hoge latency). Aan de client kant is het voor de developer veel eenvoudiger geworden omdat je nog maar één query hoeft te schrijven om data op te vragen die eerder honderden regels code en diverse API calls vereiste.

Voorbeeldje van QI.io:

To call three HTTP APIs, write this script:

prodid = select ProductID[0].Value from eBay.FindProducts where
QueryKeywords = 'macbook pro';
details = select * from eBay.ProductDetails where
ProductID in ('{prodid}') and ProductType = 'Reference';
reviews = select * from eBay.ProductReviews where
ProductID in ('{prodid}') and ProductType = 'Reference';

return select d.ProductID[0].Value as id, d.Title as title,
d.ReviewCount as reviewCount, r.ReviewDetails.AverageRating as rating
from details as d, reviews as r
where d.ProductID[0].Value = r.ProductID.Value
via route '/myapi' using method get;

and curl away

curl http://<host>:<port>/myapi

Daarmee expose je dus (via je eigen middle tier) je eigen custom api (myapi) wat een samenvoegsel is van drie eBay API's. Nu hoeft jouw software alleen 'myapi' aan te spreken om alle data op te vragen die het anders had moeten doen door de drie verschillende eBay api's aan te spreken.

Dus: developers blij (minder code te onderhouden, als API's wijzigen hoeft alleen de middle tier te worden aangepast), eBay blij (minder load op de servers en een eenvoudiger endpoint voor developers), gebruikers blij (potentieel sneller werkende sites / applicaties vanwege verminderde latency en overhead).

Het is zeker een interessante ontwikkeling en ik ga het zeker in de gaten houden

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:43]

[-=bas=-]

Als je voortbouwt op bestaande zaken dan kan je als programmeur niet rond brullen wat voor innovatieve dingen je allemaal wel niet doet.
Vanuit een egocentrisch oogpunt gezien is het niet intressant om voort te bouwen op bestaande protocollen, standaarden en ontwerpen.

[frickY]

Nooit echt het gevoel gehad iets te missen bij het aanspreken van externe API's, waardoor ik mij niet goed kon voorstellen waarom hier een nieuwe taal voor nodig zou zijn.
Tot het stukje

dat het schrijven van code om data via api's op te vragen in zijn ogen een nodeloos tijdrovend en complex proces is

.
Dat blijft inderdaad vaak een omslachtig gedoe. Al komt dat doorgaans meer door incomplete of domweg foute documentatie, het gebrek aan heldere foutmeldingen, het ontbreken van methods waardoor je zelf data van verschillende calls moet combineren, etc.

[Reactie gewijzigd door frickY op 23 juli 2024 20:43]

[Tjeerd]

Yahoo schijnt ongeveer hetzelfde te hebben gedaan met hun eigen query language: http://developer.yahoo.com/yql/

[-=bas=-]

Je maakt dan weer iets waarbij je enkel met Yahoo kunt werken (vender-lock-in)
terwijl het nog maar de vraag is of het echt zoveel uitmaakt.
Dit is allemaal leuk speelgoed tenzij misschien je bij Yahoo werkt.

[Verwijderd]

"Hierdoor zou er minder bandbreedte verbruikt worden en de latency verlaagd worden. "

"Door de taasl, Ql.io, moeten websites beter kunnen presteren."

Het doel is dus niet om het gemakkelijker te maken maar vooral sneller.

Dat het gemakkelijker / minder omslachtig wordt is natuurlijk wel een voordeel.

Men had natuurlijk ook gewoon voor een taal op basis van een 'wrapper' - library ( met als voordelen: abstraction / encapsulation / aggregation / hiding) kunnen kiezen maar daarmee wordt de snelheid niet hoger, soms zelfs lager.

Ik blijf van mening dat het uiteindelijk toch vaak een interessante optie is om maatwerk database toepassingen op zeer laag niveau te ontwerpen als het om performance gaat, dus niet alleen wat de client side betreft maar ook de server-applicatie zelf. Tussenkomst van een zware database kernel met overbodige functionaliteit zal de prestaties niet altijd ten goede komen. Er zitten dan teveel verwerkings-lagen tussen om het nog vlot te laten verlopen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:43]

[FreqAmsterdam]

Ik begrijp niet helemaal wat je nou wilt zeggen met je reactie, wat bedoel je precies met 'maatwerk database toepassing op zeer laag niveau'?

Wat ik uit de praktijk ken is dat je liever niet wil dat je frontside direct inter acteert met je database. Niet alleen om security redenen maar ook omwille van het risico dat je frontside je database onderuit schopt.

Wat je veel ziet is dat via middleware als SOAP de frontside indirect praat met je database. Dit geeft een veilig gevoel aangezien je door middel van SOAP precies in de hand hebt welke SQL's er op je database worden uitgevoerd.

Ontopic: Ik denk dat Ql.io niet handig is. Er zijn bepaalde dingen die je gewoon gescheiden wilt houden en Ql.io lijkt me dat juist tegen te gaan.

[morrowyn]

Als je moet betalen voor elke cpu cycle en bandbreedte, wat je zo'n beetje moet doen als je in amazon ec2 of app engine of azure, lijkt het me zo ie zo vanuit een zakelijk aspect een mooi voordeel. Minder kosten en efficienter omgaan met je resources.

[Xthemes.us]

Knappe jongen die sneller dan de zwaar geoptimaliseerde code van een database de juiste data weet op te vragen en dit dan ook nog in zo weinig tijd voor elkaar weet te krijgen dat het winstgevend is.
Ik denk dat in vrijwel 99.99% van de gevallen niet lukt, of je moet iemand hebben die enorm veel ervaring op dat gebied heeft of zoals hierboven staat (het amazon voorbeeld) moet het 'duur' zijn om de data op te vragen. Of eigenlijk moet het altijd een combinatie van de twee zijn want alleen de reuzen zoals ebay zouden daar anders uberhaupt aan denken.

[cyberstalker]

Ik denk dat jij het doel niet helemaal begrijpt. Het gaat erom dat er minder requests vanuit de browser worden gemaakt. Deze requests hebben vaak een grote latency, wat het gebruik van webapplicaties vaak traag kan doen aanvoelen. Door dit te minimaliseren verbetert de gebruikerservaring en wordt de gebruikte bandbreedte vermindert, en dat spaart kosten.

[-=bas=-]

Je haalt precies de punten aan zoals ik er jaren over denk.
eBay geeft je enkel een interface waarmee je bepaalde tabellen in kan lezen en hiermee de data weer moet reconstrueren om vervolgens weer data uit een andere tabel te lezen.
Als je direct op de database queries kon uitvoeren dan hadden we dat probleem niet.

Hoe een extra schil om de API heen alles sneller gaat maken is mij ook niet duidelijk.

Deze grappenmaker heeft enkel weer een laagje om een brak systeem van eBay heen gemaakt en enkel voor requests hiernaartoe zal alles wel weer makkelijker worden.
Jammer dat we dan wel weer iets van een interface nodig hebben om die query in die taal samen te stellen.
Klinkt enkel alsof je weer wat aan het verschuiven bent....

[SideShow]

Ik heb onlangs wat met de api van flickr en die van youtube gedaan ism asp.net .. ik zie persoonlijk niet in hoe nóg een andere tussenlaag het proces zal versnellen ?

[Verwijderd]

Zie mijn reactie die ik op een eerdere post schreef...

Het gaat hier met name over het gebruik van de web query language op verschillende API's van één provider (dus bijvoorbeeld alle API's van Flickr). In theorie kan je ook zelf de middle tier hosten en alle API's aanspreken die je nodig hebt. Dat kan nog steeds efficiëntere code opleveren, maar dan wordt het een afweging tussen hoe belangrijk die efficiëntere code ten opzichte van een extra hosting laag voor de middle tier.

Echter, als zowel Flickr als youtube en asp.net de web query language gaan toepassen, dan wordt het nog steeds eenvoudiger voor jou, al moet je nog steeds -minimaal- drie queries doen om de verschillende diensten te combineren. Maar dat kan nog steeds vele malen minder (en goedkoper qua latency en overhead) zijn dan hoe je het nu doet...

[Reactie gewijzigd door Verwijderd op 23 juli 2024 20:43]

[sys64738]

Hmm, gestandaardiseerde API's?!? Klinkt vrij vaag. Een API is er volgens mij om specifieke business logica te ontsluiten. Zo lang we nog geen mondiaal data model hebben (ik denk dat er eerder NS treinen naar de maan rijden dan er een mondiaal data model is.... zelfs kleine bedrijven krijgen het niet voor elkaar), valt er in mijn ogen weinig te standaardiseren aan API's.

En ik zie ook niet echt in hoe dit de IO moet verminderen? Als je minder IO wil, pas je toch gewoon je API interface aan zodat ie grotere objecten/data structuren uitspuugt. De problemen die hierboven beschreven worden (slechte docs, rare of ontbrekende foutmeldingen en zo voort) die los je hier ook niet mee op.

edit: klein -> klinkt.

@4np: Oh ja wel hoor. Het ging mij er niet om of je nou wel of geen gestandaardiseerde API's hoeft te gebruiken maar ik vind de term gestandaardiseerde API's gewoon vreemd.

En zoals ik al aangaf, kun je een api natuurlijk altijd aanpassen zodat deze veel gecombineerde aanroepen combineert.

[Reactie gewijzigd door sys64738 op 23 juli 2024 20:43]

[Verwijderd]

Nee, je hebt het nieuws bericht niet helemaal goed gelezen Er staat:

Dit wordt mede veroorzaakt doordat een programmeur afzonderlijke, al dan niet gestandaardiseerde, api's moet aanspreken.

Oftewel, er staat dat dat het nu vaak zo is dat je vaak meerdere API's moet aanspreken om data op te halen, met de web query language hoef je dus maar één query uit te voeren om hetzelfde te bereiken.

Zie ook mijn reactie op een eerdere post voor meer detail...

[Toolskyn]

Hierdoor zou er minder bandbreedte verbruikt worden en de latency verlaagd worden.

Die conclusie volg ik niet. Dit stukje code is namelijk iets wat je zelf draait, niet iets wat de API waar je een aanvraag naar wil versturen laat veranderen. Je moet nog steeds precies dezelfde requests versturen naar je API als je dezelfde data wil hebben. Het belangrijkste voordeel lijkt me dat het een en ander voor je geregeld wordt (zoals het integreren van de data), en dat dus het programmeren tegen een API minder tijd zou moeten kosten.

[Verwijderd]

Omdat jij -volgens mij- die middle tier niet host, maar de provider (dus in dit geval: eBay). Jij stuurt dus de query naar eBay, en eBay doet op hun lokale netwerk de API calls wat veel efficiënter is qua overhead en latency

[webfreakz.nl]

Er is minder HTTP verkeer nodig voor elke request die je wilt doen. Dat komt dus door de aggregatie van meerdere requests in 1 call.

Dat scheelt dus het opbouwen van een TCP/IP verbinding (zijn al 3 packets) en daarna het gebruik van HTTP GET/POST/etc. Hierna kan de verbinding weer gesloten worden (2 packets).

Met QL.io scheelt het dus in aantal te verzenden pakketten omdat ze samengevoegd worden en daardoor kan je browser minder HTTP requests doen om hetzelfde te bereiken.

[pieturp]

Wat is er mis met JSON-RPC? Kun je ook meerdere calls in één request mee maken...

Ik zie 't voordeel nog niet echt helemaal. Daarnaast is Node.js helaas(!) nog niet echt bepaald standaard aanwezig op de gemiddelde webserver, waardoor de adoption rate natuurlijk ook niet echt zal vlotten...

[Xthemes.us]

Dit lijkt me ook dan ook min of meer de officiele aankondiging dat het bestaat. Als Google met al zijn sites hier op inspringt (de translate/stock etc services) en ook facebook/flickr/twitter dan kan het hard gaan.

Google translate is waarschijnlijk een slecht voorbeeld, volgens mij wordt de API service begin 2012 gestopt.

[Verwijderd]

Daarnaast is Node.js helaas(!) nog niet echt bepaald standaard aanwezig op de gemiddelde webserver, waardoor de adoption rate natuurlijk ook niet echt zal vlotten...

Als je je daar zorgen om maakt heb je Ql.io waarschijnlijk niet nodig

[YopY]

De vraag is of je uberhaupt adoption rate wilt bij het volk dat op goedkope shared hosting zit als hostingpartij.

Aan de andere kant, een eenvoudige Node.JS applicatie kun je gewoon gratis laten hosten op Heroku. Een 'dedicated' server heb je vanaf 9 euro per maand, kun je ook Node op draaien.

[Reactie gewijzigd door YopY op 23 juli 2024 20:43]

[Verwijderd]

ql.io ziet er best interesant uit, mits het veelvuldig gebruikt gaat worden, dan is de investering in het leren van hoe het werkt het dubbel en dwars waard.

Als het maar schaars gebruikt wordt, dan is het just another api.

[-=bas=-]

Het is maar gewoon een api en meer zal het niet zijn.
Kijk naar alles wat uit google, yahoo, facebook, linkedin en ebay voort komt.
Allemaal extra layers om een probleem op te lossen met hun eigen systeem maar zelden is het innoverend genoeg dat je er iets aan hebt in algemene zin.
Google's BigTable wordt ook als een alles omvattende probleem-oplosser gepresenteerd terwijl het in de praktijk enkel goed is voor een aantal hele specifieke problemen.
Kijk kritisch naar dit soort 'innovaties' want in veel gevallen is het is enkel maar bedoeld om de ego's van de ontwikkelaars te strelen of een PR truukje om te laten zien hoe innovatief je als bedrijf wel niet bent.
De meeste innovatie vind je terug in saaie research papers van 20~30 jaar geleden....

[CiTeX]

Ik vraag me zowiezo waarom ze zoveel tijd inbesteren...
De programeerer moet die taal nu wel eerst noch leeren,waar veel meer tijd vergaar

[jjkewl]

Kom op gasten, niet iedereen is even vloeiend in Nederlands, stelling is namelijk wel relevant.

De taal die ze nu hebben ontwikkeld is niet een nieuwe taal maar een uitbreiding voor een bestaande. Dus met basis programmeerkennis kan je deze uitbreiding gebruiken om betere code te schrijven ('beter' in de agile zin).

[ronaldmathies]

Als je net zo programmeert als Nederlands schrijft dan kan ik mij dat wel voorstellen ja.

[SideShow]

Is dit zuid afrikaans ?

[Caryntjen]

Ik vind het persoonlijk goed idee, de complexiteit verminderd en de prestatie verbetert.

[Reactie gewijzigd door Caryntjen op 23 juli 2024 20:43]