O documento discute assuntos relacionados a programação assíncrona, comparando PHP e Node.js. Aborda temas como comunicação síncrona vs assíncrona, multi-threading, promises, generators e como cada linguagem lida com escalabilidade e eventos de E/S.

1. Quem?
Vinicios Neves
Analista de Sistemas na RG Sistemas, pós graduando em engenharia de
software.
RPGista, Nerd e apaixonado por algoritimos e padrões de projetos.
Projeto de maior importância: minha filha, Nathália, de 8 anos.

2. De onde surgiu esse tema?
Flamewar com um amigo no trabalho, PHP vs JS
Laravel vs NodeJS
E é lógico que o PHP venceu. #sqn

3. Comunicação síncrona
Na comunicação de dados síncrona, o dispositivo emissor e o
dispositivo receptor devem estar num estado de sincronia antes da
comunicação iniciar e permanecer em sincronia durante a transmissão.

4. Analogia
Quando eu faço uma ligação, eu disco um número e ligo pra minha
noiva. Então ela diz alguma coisa e, no mesmo instante eu a escuto.
Enquanto eu (tento) falar com ela, ela fala (muito) comigo. E, depois de
um instante (muitas horas) nós nos despedimos e 'encerramos a
transmissão‘.

5. PHP de forma síncrona
Faço uma requisição, aguardo ela ser processada, passo para a
próxima.

6. PHP... assíncrono?
Pense fora da caixinha:
• Com Websocket;
• Com icicle;
• Com reactphp;

7. THREADS

8. Qual é a diferença entre multi-threading e
programação assíncrona?
• geralmente código/linguagens assíncronas vão usar threads
• é um detalhe de implementação que é abstraído pelo usuário
• normalmente, no código assíncrono, todo o core da aplicação vai
rodar em cima de uma única thread
• outras threads são mais leves e estão apenas esperando por algo
bloqueante ou por um código de I/O ser completado
• Como? pthreads (nativo)

9. o assíncrono está na moda?
Em uma comunicação assíncrona a sincronização é diferente, o emissor
envia o fluxo de dados e periodicamente insere um elemento de sinal,
comumente chamado de flag, para que seja possível distinguir aonde
começa (a informação de início da transmissão é o start-bit) e acaba (a
informação de fim de transmissão é o stop-bit) o bloco de dados e qual
a sua posição na sequência de dados transmitidos.

10. Analogia
Eu escrevo uma carta pra minha noiva e posto numa agência dos
correios. Enquanto isso, eu não fico esperando. Faço outras coisas e,
depois de um tempo, a carta chega pra ela.
Enquanto ela recebe e começa a ler, eu continuo (jogando Skyrim)
fazendo outras coisas.
Então ela escreve uma resposta e me envia. Eu não estou envolvido
nessa parte do processo.
E, então, quando eu receber a resposta eu posso tratar isso. Posso
parar tudo o que eu estiver fazendo pra ler... ou então terminar o que
estou fazendo e só então processar a resposta.

11. Um sistema assíncrono não é, necessariamente, a
solução dos sus problemas

12. Escalabilidade
Scalability is not about using Java. A system built in any language using any
tools can be made to scale.
- Cal Henderson, 2006.

13. Pra cima ou pros lados?
• Escalar verticalmente (scale up) significa adicionar recursos em um
único nó do sistema (mais memória ou um disco rígido mais rápido).
• Escalar horizontalmente (scale out) significa adicionar mais nós ao
sistema, tais como um novo computador com uma aplicação para
clusterizar o software

14. The mighty javascript
O JavaScript sempre teve como ponto forte a possibilidade de trabalhar
de forma assíncrona e, há muito, vem evoluindo o assunto. Tivemos
uma importante explosão com o Ajax há mais de uma década e, antes
dele, já usávamos iframes para atingirmos resultados parecidos.

15. the mighty javascript

16. Navegando em marés estranhas (promise)
Promises vieram para nos ajudar a superar o famoso callback hell, uma
"pororoca" que alguns códigos acabavam se tornando!
Promises aceitam uma função por parâmetro. Esta função será
executada recebendo duas novas funções em seus argumentos - uma
para resolver a promise, outra para rejeitá-la.

17. Navegando em marés estranhas (promise)
Uma promise implementa a interface thenable e, por isso, possui dois
métodos principais:
then: Executado quando a promise é resolvida.
catch: Executado em caso de rejeição (ou throw).

18. Navegando em marés estranhas (generators)
Generators seguem um conceito onde você pode "continuar" de onde
parou anteriormente, até completar uma determinada tarefa.
Por isso, acostume-se com a ideia de interromper o fluxo de sua função
antes de terminar a tarefa, mas lembrando que a "situação" atual da
função será retomada na próxima execução para continuar de onde
havia parado.

19. this is sparta! php vs node

20. no canto esquerdo, o php
PHP é executado basicamente de duas formas: via módulo do apache
(fork) ou via FastCGI.
exemplo de fork() usando o padrão frontcontroller (laravel)

21. Fluxo do FrontController
• carregar o arquivo de configuração (se houver)
• incluir, instanciar e rodar o FrontController
• incluir, instanciar e rodar o roteamento de URL
• incluir, instanciar e rodar os métodos do Controller apropriado
• incluir, instanciar e rodar a camada de acesso aos dados
• incluir, instanciar e rodar a view apropriada.

22. Nem tudo está perdido
Usando Fast-CGI com Apache, temos um processo
do Apache (worker) que usará threads e que se
comunicará com um pool de processos PHP
usando o protocolo Fast-CGI.
Este método é mais eficiente, já que podemos
limitar a quantidade de processos PHP
executando e remove o processo PHP do Apache,
além do uso de threads, que consome menos
memória processamento.

25. C10K
Esse método foi melhorado com o advento de servidores Web capazes
de lidar com o problema C10K (10 mil conexões concorrente) como o
Lighttpd e o Nginx, que usam uma arquitetura orientada a eventos
assíncronos para lidar com as requisições.
A arquitetura de eventos assíncronos permite lidar com problem C10K
com uma única thread e menos consumo de memória enquanto que o
Apache tem dificuldade com várias threads.

26. No canto direito, o nodejs
O Node.js nasceu da necessidade de criar sites com
mensagens push (o servidor notifica o cliente) de
forma eficiente.
Javascript foi a linguagem escolhida por Ryan Dahl
por esta não possuir uma API de entrada/saída
estabelecida, o que lhe permitiu definir convenções
para entrada/saída assíncrona não bloqueante.
O uso de closures e callbacks em Javascript
encaixou-se naturalmente com o modelo assíncrono
orientado a eventos.

27. epoll()
Assim como o Apache utiliza fork() ou
pthread_create() para concorrência, o Node.js (a
libuv especificamente) usa epoll().
epoll() é um mecanismo de entrada/saída
escalável do kernel Linux, que permite esperar
por eventos de entrada/saída e ser notificado
sobre estes eventos.
Isso permite que o Node.js associe callbacks a
estes eventos, que serão executados após a
notificação.

28. Nem só de um framework viverá o homem

29. -> importação dos módulos e bibliotecas que serão
utilizados
-> instanciação ou execução de funções de configuração
etc
-> instanciação da aplicação Express -> registro dos
callbacks de middleware que processarão as requisições
-> registro das rotas de URL e callbacks que processarão
as rotas e responderão a requisição.
Só depois é que o script chama a função
http.createServer(callback).listen(port) para começar a
escutar por requisições.

30. Escale sempre: Abuse dos caches
• Page cache (varnish, squid, ngnix)
• Object cache (memcached, redis, mnesia)
• Use CDNs
• Keep it simple!
• Cace os gargalos!

31. Dúvidas? Obrigado
Vinicios Neves
marcosviniciosneves@gmail.com
@viniciosneves