Subbu Allamarajo e o time de engenharia do eBay anunciaram o lançamento da ql.io, uma linguagem específica a domínio (DSL) para facilitar a composição de APIs web, com sintaxe semelhante à do SQL.
É com prazer que anunciamos o ql.io, uma linguagem declarativa e orientada a eventos para a recuperação de informações e agregação de APIs HTTP. Com o ql.io, queremos ajudar desenvolvedores de aplicações a diminuir o número de linhas de código necessárias para invocar múltiplas APIs HTTP, e ao mesmo tempo reduzir a latência de rede e uso de banda em certos casos. O ql.io consiste de uma DSL inspirada em SQL e JSON, e um servidor baseado em node.js para processar os scripts escritos nesta linguagem.
Como indicado em notícia publicada recentemente no InfoQ.com, há vários problemas encontrados pelos desenvolvedores ao construir aplicações com APIs expostas pelo eBay:
- A maioria dos casos de uso requer acesso a múltiplas APIs, causando diversas idas e voltas na rede.
- Estas requisições de APIs frequentemente apresentam interdependências, o que requer a orquestração via programação de requisções HTTP; ou seja, fazer algumas requisições em paralelo e outras em sequência, para satisfazer as dependências e ainda assim manter pequena a latência total.
- As APIs não se mantém sempre consistentes, conforme evoluem para atender a necessidades de seus criadores; isso aumenta o ruído no código no lado do cliente necessário para normalizar as inconsistências.
Como indicam as demonstrações no site do ql.io, a tecnologia resolve estes pontos fornecendo um framework que oculta a complexidade de se integrar manualmente APIs com interdependências; ou, em um nível maior de generalização, ocultando a interação entre diferentes subsistemas. A linguagem possibilita a composição funcional semelhante ao SQL, de maneira comparável a LINQ ou YQL.
O InfoQ teve a oportunidade de conversar com Subbu Allamarajo, para entender a visão por trás do framework. A entrevista a seguir é uma tentativa de obter uma visão objetiva de como a ql.io resolve pontos problemáticos encontrados ao usar APIs, e como a nova tecnologia aumentaria a produtividade na criação de aplicações e mashups.
InfoQ: Com a solução atual, parece estar se pressupondo a confiança nas aplicações que usam as APIs. Há uma maneira de controlar usuários mal-intencionados no lado cliente? Em outras palavras, como poderiam ser estabelecidas políticas para os consumidores de APIs, tais como limites de taxa de invocação e de tempo de execução, para proteger contra consultas longas; e como essas políticas seriam configuráveis ou aplicadas?
Subbu Allamarajo: Limites de tempo e funcionalidades relacionadas ainda estão por fazer, enquanto decidimos o que limitar. Conexões de longa duração não nos preocupam tanto quanto respostas enormes, que extrapolam a coleta de lixo da máquina virtual V8. Além disso, existe a premissa que instâncias de ql.io estão rodando em ambientes controlados, sem habilidade de executar scripts arbitrários. A ql.io é modularizada de tal forma que apenas URLs específicas à aplicação são expostas a clientes. Isso permite que implantações monitorem e limitem cada URL usando ferramentas HTTP complementares.
InfoQ: O cliente está determinando o comportamento e o fluxo do servidor; isso não criaria problemas?
SA: O problema real é que otimizar uma interface para cada cliente é impraticável. Isso é frequentemente um ponto de atrito entre as equipes. Uma maneira de resolver o problema é deixar os clientes criarem novas camadas de interfaces que sejam otimizadas para suas necessidades, e é isso o que faz a ql.io.
InfoQ: Obviamente, os recursos para o projeto vêm do eBay e há bons fundamentos para o ql.io. Mas haveria algum problema ou benefício que você enxergou ao utilizar o framework internamente?
SA: O problema é geral e sentido por todo desenvolvedor de aplicações clientes que dependem de alguma API HTTP para a obtenção de dados. Vi casos em que os times criadores das APIs discordam de otimizações que consumidores das APIs implementaram, por estas otimizações estarem poluindo o código. Algumas destas são certamente questões válidas, e a ql.io pretende acelerar o trabalho dos desenvolvedores oferecendo uma maneira de criar tais otimizações. O que ainda não está validado é o caso em que a rede não é o gargalo, por exemplo quando os clientes e servidores estão na mesma rede. Estamos levantando números para definir orientações de utilização.
InfoQ: Você poderia comentar sobre algumas outras tecnologias no mercado? Por que, por exemplo, o node.js se destacou?
SA: Devido a cargas de trabalho de I/O, conexões persistentes e programação orientada a eventos, como discutido neste post.
InfoQ: Há previsão de como o framework trabalhará com hipermídia? Por exemplo, poderíamos imaginar um cenário em que o resultado de uma chamada a API é um conjunto de objetos JSON e links para outras APIs/tabelas orientadas por hipermídia mantendo a separação entre cliente e servidor?
SA: Isso já é possível hoje. Recentemente construímos uma aplicação que faz uma operação de dispersão/recolhimento baseado em URIs retornadas por um servidor. O feed tem ponteiros para outras máquinas em um grande pool [conjunto de recursos compartilhados]. Queremos possibilitar que scripts operem com qualquer parte da representação, tanto cabeçalhos como corpo; e os links fazem parte disso.
O ql.io foi publicado sob Licença Apache 2.0 e está sendo desenvolvido pelo grupo de engenharia de plataforma do eBay, sendo gerenciado ativamente no github (veja no AUTHORS.md a lista de colaboradores). A página sobre open source no eBay mostra outros projetos para as quais a empresa contribui. Visite o ql.io no github para fontes, demonstrações, exemplos e documentação do projeto.