Dosyć łatwo jest pobrać podstawowe informacje np. z Graph API Facebooka. Gorzej jest, gdy chcemy odczytać naraz więcej danych. Wprowadzony niedawno tryb bash na Facebooku, mimo swojej nazwy ma ograniczenie do 50 zapytań. To niewiele, biorąc pod uwagę fakt, że API to nie pozwala budować skomplikowanych zapytań i trzeba pobierać treści bezpośrednio, nawet tysiącami zapytań API.

Nie ma co więc nawet wspominać o późniejszym łączeniu tych danych w całość, na podobnej zasadzie jak wiążemy treści za pomocą zapytań SQL. No właśnie – najczęściej sprawa kończy się częściową replikacją bazy usługi w swojej bazie MySQL i wykonaniu zapytań SQL do tych danych.

Widać więc, jak bardzo marnotrawione są w ten sposób korzyści z udostępnionego API. Problem polega na tym, że zazwyczaj nie możemy wykonywać bardziej złożonych zapytań do interfejsu programowania po stronie dostawcy usługi, albo chociaż jakiegoś pośrednika.

Zespół programistów eBaya postanowił zmierzyć się z tym problemem i stworzyć coś na kształt SQL-a dla webowych API. W efekcie powstał projekt ql.io. Jest to stworzone na bazie serwera node.js środowisko uruchomieniowe, przetwarzające skrypty zapytań API w coś na kształt SQL-a.

Bez zbędnych detali, oto przykład zapytania ql.io:

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;

Korzyści z wykorzystania ql.io to nie tylko przejrzystszy kod i brak konieczności replikacji danych u siebie przed wykonaniem zapytania. To też lepszy kod oprogramowania i wydajność. Ostatnio zespół pomógł w migracji jednej z aplikacji, która korzysta intensywnie z API eBaya. Tak wygląda liczba zapytań do API i czas ich wykonania przed wprowadzeniem ql.io,

A tak po wprowadzeniu:

Widać znaczącą różnicę. Spadek z ponad 7 sekund do niespełna 6 to czas krótszy o ponad 15%. Transfer również został ograniczony z 273 KB do 90 KB czyli niemal o 67%. Liczba zapytań do serwera zmniejszyła z 18 do 5.

Twórcy ql.io zastrzegają, że testy były przeprowadzane na szybkim łączu, a używane API były powolne, a to oznacza, że w niektórych zastosowaniach, gdy zapytania będą jeszcze bardziej złożone, korzyści będą jeszcze większe.

ql.io może być na różne sposoby włączone do istniejącego oprogramowania. Może znaleźć się w warstwie reverse proxy, na przykład między load-balancerami a serwerami API, albo bliżej aplikacji klienckich.

Najwyraźniej więc JavaScript i przez wielu krytykowany node.js mogą przydać się do czegoś poważnego. Twórcy rozwiązania chwalą sobie wydajność, skalowalność, małe zużycie pamięci przez połączenia (2 KB), możliwość szybkiej iteracji nad projektem i obsługę przez standardowy serwer Ubuntu do 120 000 aktywnych połączeń na węzeł.

Jedyne narzekania ze strony społeczności dotyczą tylko tej kwestii, że eBay wymyśla nowy język zamiast korzystać ze standardów.

Tutaj znajdziecie przewodnik po ql.io, a pod tym adresem konsolę do testowania zapytań. Strona projektu na Githubie to github.com/ql-io/ql.io a grupa dyskusyjna poświęcona projektowi działa pod groups.google.com/group/qlio?pli=1

źródło: ebaytechblog.com