DEV Community: Alex Ribeiro

EDA — Arquitetura Orientada a Eventos

Alex Ribeiro — Mon, 18 Nov 2019 12:00:16 +0000

EDA — Arquitetura Orientada a Eventos

Nessa postagem tenho como objetivo trazer um resumo do funcionamento de uma de sistemas onde seus componentes se comunicam entre si por meio de eventos, de forma rápida e assíncrona. Espero que o conhecimento aqui exposto auxilie em futuras tomadas de decisões. Vamos lá?!

O que é?

Arquitetura Orientada a Eventos (EDA) é um paradigma de programação. É basicamente o efeito de um ação e reação, onde de acordo com algum acontecimento/evento dentro do sistema pode ou não gerar um novo processo, como o nome já diz: orientado a eventos.

Esse evento pode ser qualquer coisa dentro do sistema, desde um log a ser gerado, um novo registro sendo inserido no banco de dados, o clique de um mouse… Enfim, existem eventos em praticamente todos os ecossistemas técnicos de nosso dia a dia.

Como funciona?

De forma simples, o processo seria dividido nos seguintes passos:

Um evento é publicado em um barramento/fila
Os serviços interessados consomem e reagem aos eventos

Aprofundando um pouco existem 2 modelos de eventos: o modelo de pub/sub e o modelo de fluxo de evento.

Pub/Sub : a infraestrutura de mensagens acompanha o controle de assinaturas. Quando um evento é publicado, ele envia o evento para cada assinante. Depois que um evento é recebido, ele não pode ser reproduzido e não será exibido para assinantes novos.

Streaming de eventos : eventos são gravados em um registro. Os eventos são ordenados e duráveis. Os serviços não assinam o fluxo, em vez disso, um cliente pode ler a partir de qualquer parte do fluxo. O serviço é responsável por avançar a sua posição no fluxo. Isso significa que um serviço pode reagir a qualquer evento que já tenha sido gerado.

No desenho acima, existe uma etapa central (Event Ingestion) que pode ser um mediador ou um broker de eventos.

Event Ingestion

Mediador

Usada principalmente quando há necessidade de orquestração ou manipulação de etapas no processamento do evento. Tendo como tipos de componentes a fila, mediador, canais e processador (todos de eventos).

Exemplos de implementações : Apache Camel, Spring Integration ou Mule ESB.

Broker

Usada quando se tem um fluxo de eventos simples, onde não há necessidade de orquestração dos eventos. Este componente pode ser centralizado ou federado e contém os canais de eventos usados no fluxo, sendo os canais modelo de filas, tópicos de mensagens ou a combinação deles.

Exemplos de implementações: AWS SQS, Apache ActiveMQ, Apache Kafka.

Padrões

Notificação de evento

O produtor do evento gera um evento e o envia para um broker de eventos, por exemplo, informando que houve uma alteração de endereço. Os interessados neste evento (no caso os consumidores) serão notificados. Neste modelo, os dados relacionados ao evento não estão nele! Diferente do caso da alteração do endereço, o consumidor queria saber qual é o novo bairro e a rua. Para isso, ele deverá realizar uma consulta no sistema que produziu o evento!

Transferência de estado transportado pelo evento

O evento leva os dados relacionados à ele. Neste caso, o consumidor não precisa consultar o produtor para obter mais informações. Com isso, o consumidor não depende de dados de outra aplicação e disponibilidade para fazer o que precisa ser feito, garantindo assim resiliência e disponibilidade no processo executado pelo consumidor, porém isso irá gerar maior complexidade do lado do consumidor por conta de que os dados são de outro domínio.

Fonte de eventos (Event Sourcing)

Modelo muito utilizado para armazenamento de eventos , criando um histórico de eventos. Na prática, isso nos permite realizar auditoria dos dados e retroceder determinado ponto de estado. Como quando existe alguma inconsistência, por exemplo, e é necessário validar o que foi realizado. Com um histórico, também podemos analisar comportamentos e gerar análises de negócio sobre as informações geradas. Este modelo é muito usado com o padrão CQRS (Command Query Responsibility Segregation), que separa escrita de leitura. Nesta mescla dos padrões vocês vão encontrar o event sourcing sendo a fonte de escrita, que muitas vezes possui um Handler, que faz a gestão e distribuição destes dados para bases de consulta. A abordagem de event sourcing hoje é amplamente aplicada e vai desde cases de Internet da Coisas a Data Science.

Quando usar?

Vários subsistemas devem processar os mesmos eventos.
Processamento em tempo real com retardo mínimo de tempo.
O processamento de eventos complexos, como a correspondência de padrões ou agregação em janelas de tempo.
Alto volume e alta velocidade de dados, como IoT.

Vantagens

Produtores e consumidores são separados, aumentando a resiliência e desacoplamento.
Altamente escalável e distribuído.
Os consumidores podem responder aos eventos imediatamente assim que chegarem, resultando em operações assíncronas.
Os subsistemas têm exibições independentes do fluxo de evento.
Entrega contínua.

Desvantagens

Dependendo da situação, estes são pontos negativos:

Muita concorrência.
Pode haver perda de informação
Pode adicionar mais complexidade se mal implementada
A garantia de entrega é um problema em grandes volumes
Desafio para a governança de dados e fluxo.

Referências

Git: Um grande aliado

Alex Ribeiro — Thu, 14 Jun 2018 13:08:00 +0000

“A pendrive in the USB port of a laptop” by Brina Blum on Unsplash

Para quem já é da área de desenvolvimento ou já trabalhou com versionamento de algum projeto, certamente já ouviu falar de Git.

Se ainda não domina esta ferramenta, continue lendo esta postagem que poderá te ajudar em seus projetinhos atuais e futuros.

Antes de adentrarmos no conceito do que é Git, é importante compreender o que é Controle de Versão, pois o Git (assim como outros semelhantes) utiliza-se deste sistema para fazer o que faz de melhor.

Segundo a própria documentação que se encontra no site do Git:

O controle de versão é um sistema que registra as mudanças feitas em um arquivo ou um conjunto de arquivos ao longo do tempo de forma que você possa recuperar versões específicas.

Outros controles que podemos ter com essas premissas de um controle de versão é a possibilidade de identificar quem é responsável por qualquer modificação, assim como mapear origem de bugs e até mesmo comparar o avanço das mudanças feitas no decorrer do tempo.

Isso é demais! Imagina quanta segurança e praticidade que isso proporciona sobre nossos projetos?! Alguns pontos importantes:

Integridade: controle sobre qualquer alteração nos arquivos ou estrutura do projeto;
Autenticidade: controle sobre as propriedades e origem dos arquivos de forma a comprovar quem é responsável ou quem alterou algo;
Disponibilidade: dependendo de onde os arquivos estiverem armazenados, pode-se acessar os projetos de qualquer máquina pela internet ou rede local;
Confidencialidade: dependendo de como e onde os arquivos estiverem armazenados, pode-se ter controle de autorização de acesso aos mesmos.

Incrível o quanto essa ferramenta pode fazer, néh?!

Afinal, o que é Git?

Git é um sistema de controle de versão de arquivos de forma distribuída, permitindo até mesmo que mais de uma pessoa trabalhe no mesmo projeto.

Existem diversos sistemas de controle de versão, mas o diferencial do Git é seu foco em velocidade, colocando maior parte dos controle de forma local sem necessidade imediatada de alguma conexão com o repositório principal.

Outro ponto diferencial do Git é a forma como versiona e garante a integridade dos arquivos, pois ele utiliza-se da ideia de branchs (semelhante ao que seriam snapshots), que podem ser criadas a qualquer instante, ou seja, nos permite ter cópias do mesmo projeto e na mesma pasta.

Um exemplo simples e prático da utilização dessas vantagens do git: Estou com meu website na branch principal (master) e quero testar algo novo sem interferir no que está pronto e funcional. Crio uma nova branch, a partir dela já poderei alterar o que quiser do projeto. Assim que tudo estiver pronto e testado, pego essas alteração e faço uma união com a branch principal (esta união é chamada de merge). Caso ocorra algum problema na branch principal, posso reverter facilmente qualquer alteração feita para um estado anterior.

Lista de comandos

Git possui uma variedade de ferramentas que podem ser utilizadas por comandos via terminal. Pode conferir estes comandos logo abaixo.

Criar

Clona um repositório existente:

$ git clone ssh://user@domain.com/repo.git

Cria um novo repositório local:

$ git init

Modificações locais

Arquivos modificados no diretório ativo:

$ git status

Modificações em arquivos versionados:

$ git diff

Add all current changes to the next commit:

$ git add .

Adiciona as mudanças do <file> no próximo commit:

$ git add -p \<file\>

Commita todas as modificações de arquivos versionados:

$ git commit -a

Commita modificações preparadas:

$ git commit

Modifica o último commit:

$ git commit --amend

Linha do tempo

Mostra todos os commits, começando pelo mais novo:

$ git log

Mostra as modificações para um arquivo específico:

$ git log -p \<file\>

Quem mudou o quê e quando em um arquivo:

$ git blame \<file\>

Branchs e tags

Lista todas as branches existentes:

$ git branch -av

Muda a branch atual:

$ git checkout \<branch\>

Cria uma branch a partir do HEAD atual:

$ git branch \<new-branch\>

Deleta uma branch local:

$ git checkout --track \<remote/branch\>

Delete a local branch:

$ git branch -d \<branch\>

Marca o commit atual com uma tag:

$ git tag \<tag-name\>

Atualizar e publicar

Lista todos os remotes configurados atualmente

$ git remote -v

Mostra informações sobre um remote:

$ git remote show \<remote\>

Adiciona um novo repositório remoto, nomeado <remote>:

$ git remote add \<shortname\> \<url\>

Baixa todas as modificações do <remote>, mas não integra ao HEAD:

$ git fetch \<remote\>

Baixa as modificação e automaticamente faz o merge:

$ git pull \<remote\> \<branch\>

Publica as modificações locais em um remote:

$ git push \<remote\> \<branch\>

Deleta uma branch no remote:

$ git branch -dr \<remote/branch\>

Publica suas tags:

$ git push — tags

Merge e rebase

Fazer merge da <branch> no HEAD atual:

$ git merge \<branch\>

Fazer rebase do seu HEAD na <branch>:

$ git rebase \<branch\>

Abortar um rebase:

$ git rebase --abort

Continuar um rebase depois de resolver conflitos:

$ git rebase --continue

Usar a sua ferramente de merge configurada para resolver conflitos:

$ git mergetool

Use seu editor para resolver conflitos manualmente e marcar o arquivo como resolvido:

$ git add \<resolved-file\>

$ git rm \<resolved-file\>

Desfazer

Descarta todas as mudanças locais no diretório atual:

$ git reset --hard HEAD

Descarta mudanças locais em um arquivo específico:

$ git checkout HEAD \<file\>

Reverte um commit (criando um novo com as modifições ao contrário):

$ git revert \<commit\>

Reseta o ponteiro do HEAD para um commit anterior

…e descarta as modificações desde então:

$ git reset --hard \<commit\>

…e preserva todas as modificações como modificações não preparadas:

$ git reset \<commit\>

…e preserva modificações locais não commitadas:

$ git reset --keep \<commit

Eu sei, é muita coisa.

Workflow básico

O fluxo de trabalho com o Git geralmente é uma sequencia bem simples:

Você modifica o arquivo ou grupo de arquivos no seu diretório de trabalho;
Você seleciona os arquivos, adicionando snapshots deles para sua área de preparação;
Você faz um commit, que leva os arquivos como eles estão na sua área de preparação e os armazena permanentemente no seu diretório Git.

Dica

Se você quiser ou precisar praticar os principais fluxos de trabalho com o Git, recomendo esse site: http://aprenda.vidageek.net/aprenda/git.

Por ele poderá praticar de forma simplificada e objetiva os diversos comandos do Git.

Referências

Obrigado e até mais!

Se gostou do meu texto, me acompanhe que em breve estarei trazendo novidades.

Quer saber mais sobre o assunto ou tem alguma dúvida? Deixe um comentário. Ah, estou aberto a críticas também.

Abraço!

Node.js: Como criar um servidor HTTP

Alex Ribeiro — Mon, 19 Mar 2018 00:34:44 +0000

Nessa postagem, irei mostrar a vocês como é simples criar um servidor HTTP, mais conhecido como servidor Web, utilizando Node.js.

Caso tenha alguma dúvida sobre o que é Node.js, dê uma lida em minha postagem onde explico de forma simplificada clicando aqui.

Criando um servidor HTTP

Pressupondo que já tenha o Node.js instalado em sua máquina. Vamos criar um arquivo chamado app.js com a seguinte estrutura:

Toda vez que o servidor HTTP recebe uma requisição, a função de callback passada para o método createServer é executada.

O método listen é o responsável pela parametrização de endereço e porta, escutando os mesmos, possibilitando a execução do servidor.

Perfeito. Todos as linhas necessárias para a criação de nosso servidor estão prontas. Agora só precisamos iniciar o servidor.

Pelo terminal, vá até a pasta onde se encontra o arquivo app.js e execute o seguinte comando: node app.js.

A saída no terminal será:

Servidor rodando em http://localhost:3000

Parar o servidor com: ctrl + c

A partir de agora, seu servidor Web está rodando! Se tudo estiver correto, ao acessar http://localhost:3000 pelo navegador e terá o mesmo retorno da linha 7: Retorno da requisição.

Servidor configurado e funcionando! Porém, qualquer caminho vai dar o mesmo retorno. Como iríamos configurar diversas rotas com essa estrutura atual?

Calma, meu caro leitor! Irei lhe mostrar uma forma simples e funcional para isso. Vamos lá!

Trabalhando com rotas

Sabendo como funciona o fluxo de requisições no servidor, podemos adicionar poucas linhas ao nosso código atual para termos um controle de rotas simples e funcional:

Pronto, agora temos um controle de rotas funcional. Se cancelar a execução atual do servidor com ctrl+c e rodar novamente o comando node app.js poderá testar as as rotas.

Viu só como é simples?! Com poucas linhas temos uma estrutura capaz de receber requisições e dar um retorno baseado em rotas dinâmicas. Brilhante, não?!

Apesar de funcional, essa estrutura é difícil de se manter. Por diversos motivos a comunidade de JavaScript começou a criar frameworks (novidade?!) para cuidar das rotas.

A partir deste ponto, podemos construir diversas outras formas de organização e tratamento dos retornos. Deixo essa tarefa com vocês.

Obrigado e até mais!

Se gostou do meu texto, me acompanhe que em breve estarei trazendo novidades.

Quer saber mais sobre o assunto ou tem alguma dúvida? Deixe um comentário. Ah, estou aberto a críticas também.

Abraço!

Gearman — Um breve resumo

Alex Ribeiro — Fri, 23 Feb 2018 12:31:41 +0000

Gearman fornece um framework/aplicação genérica para explorar o trabalho de outras máquinas ou processos mais adequados para um determinado trabalho.

Permite que você trabalhe em paralelo, equilibrar processamento e chamar funções entre linguagens distintas.

Ele pode ser utilizado em uma variedades de aplicações, desde sites de alta disponibilidade até o transporte de eventos de replicação de banco de dados.

Em outras palavras, é o sistema nervoso de como o processamento distribuído se comunica.

Alguns pontos fortes sobre Gearman:

Open Source
Multi-linguagem
Flexível
Rápido
Incorporável
Nenhum ponto de falha
Sem limites no tamanho dos dados
Escalável

Instalação

Esta instalação tem como foco a possibilidade de executar scripts com PHP. Caso não seja necessário o uso do PHP, seguir somente até o segundo passo e retirar referências ao PHP.

1. Instalar e atualizar o Gearman PPA

$ apt-get install software-properties-common
$ add-apt-repository ppa:gearman-developers/ppa
$ apt-get update

2. Instalar Gearman e outros componentes e ferramentas

$ apt-get install gearman gearman-tools gearman-job-server libgearman-dev php7.0-dev php-pear wget unzip re2c
$ apt-get upgrade

3. Baixar, compilar o gearman pecl module e adicionar ao php.ini

$ cd /tmp/
$ wget [https://github.com/wcgallego/pecl-gearman/archive/master.zip](https://github.com/wcgallego/pecl-gearman/archive/master.zip)
$ unzip master.zip
$ cd pecl-gearman-master
$ phpize
$ ./configure
$ make
$ make install
$ echo "extension=gearman.so" \> /etc/php/7.0/mods-available/gearman.ini
$ phpenmod -v ALL -s ALL gearman

4. Reiniciar o Apache2 ou PHP FPM

$ service php7.0-fpm restart
$ service apache2 restart

Execução

Executar o servidor Gearman com o seguindo comando:

$ gearmand -d

Verificar o status do servidor:

$ gearadmin --status
worker 0 1 2

Na linha de resposta do status, respectivamente, temos o nome da função (worker), o número de tasks na fila (0), o número de jobs rodando (1) e o número de workers capazes (2).

Ferramentas de linha de comando

Gearman

Com o Gearman, você pode executar funções de clients e workers por linha de comando.

$ gearman -H
Common options
 -f \<function\>
 Function name to use for jobs (can give many)

 -h \<host\>
 Job server host

 -H
 Print this help menu

 -p \<port\>
 Gearman server port

 -t \<timeout\>
 Timeout in milliseconds

 -i \<pidfile\>
 Create a pidfile for the process

 -n
 In client mode run one job per line, in worker mode send data packet for each line

 -N
 Same as -n, but strip off the newline

Client options
 -b
 Run jobs in the background

 -I
 Run jobs as high priority

 -L
 Run jobs as low priority

 -P
 Prefix all output lines with functions names

 -s
 Send job without reading from standard input

 -u \<unique\>
 Unique key to use for job

Worker options\*
 -c \<count\>
 Number of jobs for worker to run before exiting

 -w
 Run in worker mode

Gearmand

Gearmand é utilizado para iniciar e parametrizar o servidor via linha de comando.

$ gearmand -h
General options
 -b [--backlog] arg (=32)
 Number of backlog connections for listen.

 --check-args
 Check command line and configuration file argments and then exit.

 -d [--daemon]
 Daemon, detach and run in the background.

 -f [--file-descriptors] arg
 Number of file descriptors to allow for the process (total connections will be slightly less). Default is max allowed for user.

 -h [--help]
 Print this help menu.

 -j [--job-retries] arg (=0)
 Number of attempts to run the job before the job server removes it. This is helpful to ensure a bad job does not crash all available workers. Default is no limit.

 -l [--log-file] arg
 Log file to write errors and information to. Turning this option on also forces the first verbose level to be enabled.

 -L [--listen] arg
 Address the server should listen on. Default is INADDR\_ANY.

 -p [--port] arg (=4730)
 Port the server should listen on.

 -P [--pid-file] arg
 File to write process ID out to.

 -r [--protocol] arg
 Load protocol module.

 -R [--round-robin]
 Assign work in round-robin order per worker connection. The default is to assign work in the order of functions added by the worker.

 -q [--queue-type] arg
 Persistent queue type to use.

 -t [--threads] arg (=4)
 Number of I/O threads to use. Default=4.

 -u [--user] arg
 Switch to given user after startup.

 -v [--verbose] arg (=v)
 Increase verbosity level by one.

 -V [--version]
 Display the version of gearmand and exit.

 -w [--worker-wakeup] arg (=0)
 Number of workers to wakeup for each job received. The default is to wakeup all available workers.

HTTP:
 --http-port arg (=8080)
 Port to listen on.

 sqlite
 --libsqlite3-db arg
 Database file to use.

 --libsqlite3-table arg (=gearman\_queue)
 Table to use.

 Memcached(libmemcached)
 --libmemcached-servers arg
 List of Memcached servers to use.

 Drizzle/MySQL(libdrizzle)
 -host arg
 Host of server.

 -port arg
 Port of server. (by default Drizzle)

 -uds arg
 Unix domain socket for server.

 -user arg
 User name for authentication.

 -password arg
 Password for authentication.

 -db arg
 Schema/Database to use.

 -table arg
 Table to use.

 -mysql arg
 Use MySQL protocol.

 Postgres
 --libpq-conninfo arg
 PostgreSQL connection information string.

 --libpq-table arg (=queue)
 Table to use.

Gearadmin

Gearadmin é uma ferramenta de linha de comando para manipular os servidores do Gearman.

$ gearadmin --help
--help
Provice help about the program.

--create-function
Create a function from the server.

-h [--host] arg (=localhost)i
Connect to the host

-p [--port] arg (=4730)
Port number or service to use for connection

--drop-function
Drop a function from the server.

--server-version
Fetch the version number for the server.

--server-verbose
Fetch the verbose setting for the server.

--status
Status for the server.

--workers
Workers for the server.

--shutdown
Shutdown server.

Exemplo

Vamos criar dois scripts PHP, um será para o client e o outro para o worker.

Client:

\<?php
$client = new GearmanClient();
$client-\>addServer();
print $client-\>do("reverse\_string", "Hello World!");

Worker:

\<?php
$worker = new GearmanWorker();
$worker-\>addServer();
$worker-\>addFunction("reverse\_string", function ($job) {
 return strrev($job-\>workload()) . "\n";
});
while ($worker-\>work());

Execução do Worker:

Foi executado o script worker.php em segundo plano.

Ao verificar o status do servidor, pode-se notar que foi registrado a função reverse_string com um worker registrado como capaz.

Caso seja executado uma segunda vez o mesmo worker, a quantidade de workers capazes irá mudar.

Execução do Client

Ao executar o client.php, já obtivemos o retorno programado no worker. Com isso, validamos que o mesmo está funcionando.

Conclusão

Esta aplicação é ótima para diversas situações onde se encontra a necessidade de controlar processos específicos, aliviando o uso acumulado dos recursos do servidor.

Referências

Gearman — http://gearman.org/

Obrigado e até mais!

Se você gostou do texto, me acompanhe e terá mais informações em breve.

Quer saber mais sobre o assunto ou tem alguma dúvida? Deixe um comentário. Ah, estou aberto a críticas também.

O que é Node.js?

Alex Ribeiro — Thu, 04 Jan 2018 08:01:01 +0000

Imagem por Node.js Foundation

Node.js é um runtime de JavaScript, criado por Ryan Dahl em 2009. Foi desenvolvido em cima do motor JavaScript V8 — engine criada pelo Google e utilizado no Chrome e Chromium — , que leva o processamento e renderização do JavaScript para o lado do servidor.

Node.js usa um modelo de I/O não bloqueante orientada a evento que o torna leve e eficiente, que possibilita criar aplicações rápidas, escaláveis e estáveis. Desde seu surgimento, vem ganhando crescente espaço entre profissionais de tecnologia do Brasil e do mundo.

Já pensou, poder utilizar javascript no back-end , com a mesma segurança proporcionada por linguagens como PHP e ASP.NET?!

Para quem já tem certa experiência com desenvolvimento web (certamente conhece a limitação de uso do Javascript no front-end ) nunca iria imaginar essa possibilidade.

Agora estamos em uma era diferente, onde praticamente todas as grandes limitações do Javascript não existem mais. A cada dia infinitas possibilidades surgem e diversas referências vem aderindo a esse avanço.

Por que (e quando) utilizar Node.js?

Vou listar pontos cruciais, alguns já mencionados anteriormente, que irão te esclarecer o porquê de utilizar o Node.js:

Assíncrono ;
I/O sem bloqueios ;
Alta performance ;
Escalabilidade fácil e barata ;
Loop de eventos.

Um detalhe que toma a dianteira em relação aos concorrentes é o loop de eventos. Irei explicar melhor como isso funciona.

Geralmente, um jeito “tradicional” de lidar com muitas requisições é criando múltiplas threads, ou seja, para cada requisição é criada uma thread. Nela é tratada a requisição e somente após o retorno deste tratamento a thread é finalizada. Porém, muito recurso é gasto nesse processo e muitas vezes de forma desnecessária, já que nem sempre todo aquele recurso reservado é utilizado e a thread fica “estacionada” enquanto o tratamento não estiver concluído.

Quando uso o termo “tratamento” me refiro a qualquer processo feito antes de devolver uma resposta, seja uma consulta no banco, verificação de arquivo, cálculo…

Já o Node.js, trata toda e qualquer requisição em uma única thread.

Aí você me pergunta: Então como é possível ele ser tão performático?

Quando ele recebe uma requisição, ao invés de esperar o resultado do tratamento desta, ele segue com a próxima requisição e assim por diante, como uma fila. Quando alguma requisição em espera tiver seu tratamento finalizado, é sinalizado um evento que a retornará o quanto antes.

Isso quer dizer que, com o Node.js, temos um ganho muito grande de número de requisições que podem ser processadas.

Node.js não é apenas um servidor, já que hoje em dia pode ser utilizado para criar até mesmo aplicações desktop. Também é ótimo para realizar diversos tipos de projetos, como:

APIs (principal uso);
Aplicações web real-time como servidores de chat ou aplicações colaborativas entre múltiplos usuários (socket);
Jogos multiplayer;
Aplicações que demandam alta escalabilidade;
Servidores de streaming de dados;

Quando não utilizar?

Por usar somente uma thread, ele não serve para lidar com algoritmos complexos que consumam muita CPU, como edição de imagens, por exemplo. Isso impediria a execução de outras ações até o processamento estar completo.

Quem já utiliza?

Então quer dizer que não é só uma “modinha”?

Aqui vai uma lista de empresas conhecidas que utilização esta linda tecnologia:

Walmart;
PayPal;
Groupon;
Netflix;
LinkedIn ;
New York Times;
Flickr ;
Mozilla ;
Yahoo.

Obrigado e até mais!

Esta é minha primeira postagem. Se você gostou do meu texto, me acompanhe e terá mais informações em breve.

Quer saber mais sobre o assunto ou tem alguma dúvida? Deixe um comentário. Ah, estou aberto a críticas também.