.png){kind=small}
.png){kind=small}
A cada dia você vê novas tecnologias sendo comentadas na comunidade de desenvolvedores e tendências para empresas serem mais modernas e rápidas. Com todas as novas opções pipocando em notícias, uma delas me chama muito a atenção pelo potencial de uso, otimizando de forma animadora o mundo dos dispositivos móveis.Essas belezinhas são as Streaming APIs. Já falei um pouco delas para você neste post, porém hoje vou entrar em mais detalhes que vão te surpreender.Olha só!
Se você ainda não sabe o que é uma API, eu sugiro que leia este artigo, onde está explicado em detalhes o que é uma API e como elas funcionam. Porém, se você já conhece este conceito vamos a principal diferença!Uma API comum funciona de como uma troca de pedido e respostas, ou seja, a cada ordem submetida pelo cliente, o servidor irá retornar uma resposta. Uma analogia bem interessante que indica esse funcionamento é a de um restaurante. Se você é um leitor assíduo do blog já deve ter lido por aqui (ou no link que coloquei acima), mas vamos lá.Em um restaurante, o cliente realiza um pedido para o garçom, que leva o seu desejo para a cozinha, e o seu prato começa a ser preparado, até que fica pronto e logo estará a caminho.Esta é a maneira bem resumida do funcionamento de uma REST API, na qual o cliente faz o consumo de um serviço através de um request (através da API, o garçom) e o servidor (cozinha) irá preparar e entregar a resposta ao garçom, que retorna a quem pediu.Para você aprender tudo sobre o Design de uma API REST, recomendo que assista este webinar (gratuito).Para exemplificar, existe este desenho simplificado.
Agora, a pergunta vital para esse artigo:E se após o primeiro pedido, o garçom e a cozinha já soubessem o seu próximo prato?Bom, esse é basicamente o funcionamento de uma Streaming API. Com elas a conexão entre o Cliente e o Servidor fica aberta o tempo necessário após o primeiro request, e não é fechada imediatamente a cada requisição, fazendo com que o servidor envie sempre novos dados enquanto eles ainda existam para aquele tipo de requisição.Ou seja, não é necessário se preocupar em fazer novos pedidos para conseguir informações diferentes da mesma chamada, da maneira que mostra o desenho:
Continuando a analogia, é como se fosse um rodízio! Você chega ao restaurante, se senta e é atendido por um garçom. Depois disso, você pode até interagir com o garçom e pedir coisas específicas, mas a comida irá continuar vindo, mesmo que você não fale mais nada.E você fica feliz =)Para esta maravilha acontecer, é necessário que o Cliente esteja preparado para manter a conexão aberta o tempo necessário até não existir mais updates sobre aquela requisição, e assim encontramos o maior empecilho desta tecnologia.
Por esta tecnologia utilizar como base o protocolo HTTP, as requisições para o Servidor são realizadas através de browsers em sua maior parte, e estes por sua vez fazem o papel do Cliente nas chamadas.Porém não são todos os Clientes que estão preparados para a implementação de uma Streaming API.Sendo assim, caso você queria utilizar deste tipo de API, é necessário construir uma conexão que se mantenha viva em seu código, com temporizadores que acabam deixando a sua API um pouco "deselegante".Desta maneira, é necessário buscar novas alternativas em outras tecnologias que conseguem dar um suporte a este tipo de chamada, abrindo um canal entre Cliente e Servidor e deixando a comunicação entre eles de maneira mais simplificada.É claro, não podemos deixar o HTTP de lado, pois estaríamos perdendo um protocolo largamente utilizado. Sendo assim, é possível fazer a reutilização das chamadas de APIs já existentes.Pensando então nos requisitos básicos para este modelo temos:
Pensando em todos os princípios descritos acima, chegamos a uma tecnologia que consiga atender de forma concisa todos os requisitos que precisamos para ter praticamente uma Streaming API: o WebSocket.O funcionamento dele é baseado em um canal aberto entre o Cliente e o Servidor. Apesar de ser utilizado como um portal para as chamadas de APIs, o túnel aberto é baseado no protocolo TCP (lembra da dupla TCP/IP?).Quero deixar claro aqui que todas as suas APIs vão ser utilizadas e implementadas da mesma maneira, e a utilização do WebSocket é realizada para manter uma conexão bi-direcional e full duplex entre o seu Cliente e Servidor, da forma como desejamos no final da seção anterior.Para criar o WebSocket, existe o esquema ("schema") de conexão WS que é similar a uma conexão HTTP, e para aumentar a segurança da troca de dados, como temos no HTTPs, é implementado o esquema WSs.Veja um exemplo de uma abertura de conexão WS:
var connection = new WebSocket ('ws://html5rocks.websocket.org/echo', ['soap', 'xmpp']);
Apesar de a tecnologia também ser novidade no mercado, a utilização dela só vem crescendo conforme o tempo passa, e com a popularização, as evoluções já são nítidas.Com isso, praticamente todos os Browsers já conseguem suportar estas chamadas, facilitando ainda mais o trabalho de sua API.Pelas ferramentas necessárias para a implementação do WebSocket já estarem prontas, indico a utilização desta tecnologia o mais rápido possível.É claro, faça isso caso o seu serviço tenha uma necessidade de alimentar o cliente com novas informações de forma recorrente. Se o seu restaurante não for rodízio, não precisa se preocupar ;)Alguns exemplos interessantes além de stream de vídeo para este tipo de utilização são chats e feed de notícias. Portanto, se o seu negócio ronda esses princípios de estratégias, olhe para esta tecnologia com muito carinho!
Até o momento, te apresentei dois mundos paralelos.Um deles sendo a especialização da REST API, que é o protocolo mais utilizado hoje, mas que os Clientes ainda não estão prontos para utilizar.No segundo, uma nova tecnologia que está sendo muito utilizada, e que consegue realizar os túneis necessários para uma comunicação contínua entre Cliente e Servidor, os WebSockets.Porém, como a tecnologia de WebSocket é voltada para Web, mas não otimizada para a mobilidade de informações, a programação acaba sendo bem mais complexa e os pacotes de dados muito mais pesados.Sendo assim, o consumo de bateria dos dispositivos móveis acaba sendo muito alto com este tipo de tecnologia. Como bateria é uma das principais e mais básicas preocupações dos dispositivos móveis, isso pode inviabilizar várias APIs.Ou seja, hoje, WebSockets são uma bela mão na roda, mas acabam sendo um pouco custosos em certos sentidos.Pensando desta maneira, seria interessante implementarmos hoje o WebSocket, e em um futuro no qual os browsers vão estar totalmente prontos para as Streaming APIs, realizarmos a alteração.Assim, tanto os browsers quanto os dispositivos mobile poderão tirar proveito das Streaming APIs!Todos esses fundamentos possuem um conceito muito forte do seu negócio ser baseado em Microservices, e possuir uma arquitetura bem organizada.Já falamos bastante sobre isso no passado, e para você ficar atualizado, basta assistir esse webinar.
A alteração de padrão REST pela implementação de Websockets vem se tornando uma tendência em projetos que envolvem de certa forma "Streaming" de informações.Porém, a comunidade possui uma certa desconfiança a esta mudança, pois se os browsers não se adaptarem rapidamente as Streaming APIs a mudança de padrão pode "quebrar a web", criando um paralelo entre os protocolo HTTP e o de WebSockets.Por outro lado, o avanço de todas as ferramentas e até mesmo do WebSocket, nos faz acreditar que o aprimoramento é inevitável, e como o HTTP é o protocolo mais utilizado nos dias atuais, a convergência para uma adaptabilidade, podendo ter os dois formatos utilizados em conjunto, é o mais provável.Estaremos de olho!
---Curtiu o artigo? Você sabia que estamos vivendo a Era das APIs? Sim, elas já fazem parte da minha, da sua e da vida de todos! Esse é o Poder das APIs. Se quiser conferir um conteúdo onde exploramos mais essa ideia, clique aqui ou na imagem abaixo:
