Descomplicando Server-Sent Events: Aprenda o básico em minutos | Dias de Dev

[@gssj-o8p]

Não fazia ideia que era assim, vivendo e aprendendo com Vinicius Dias! =D

[@DiasDeDev]

Valeu demais pela moral de sempre, Guilherme. Que bom que tem gostado do conteúdo. :-D

[@josuelrocharodrigues]

Boa Vinicius, não sei se chegou a ver meu comentário em um outro vídeo seu, mas por fim das dúvidas ou dar um ctrl + c e ctrl + v nele: Fala Vinicius, blz?! Parabéns pelo vídeo, seus vídeos agregam muito na evolução profissional dos devs. Queria fazer uma sugestão de vídeo: Fala sobre a modernização do php, pois ainda hoje vejo projetos sendo criados não usando as ferramentas mais modernas que temos, por exemplo, novos projetos sendo criados usando php + servidor web tradicional (apache, nginx etc), sendo que já temos maneiras mais modernas, mais eficientes e com mais performance para rodar um projeto em php e de maneira independente, sem precisar de um servidor web, sem configurar PHP-FPM e etc, no caso estou falando do php + roadrunner ou php + swoole, assim como aplicações node.js, o projeto pode ser publicado e ser rodado no próprio php, além do projeto ter performance maior, o deploy também é muito mais simples, muito parecido com deploy de aplicações node.js, basicamente é fazer o push, rodar o install do composer e pronto (falando de um modo geral, é claro, tem coisas que precisam de uma configuração extra). Hoje todos os meus projetos em php são em roadrunner ou swoole, e foi uma das melhores escolhas que fiz, não ter mais que ficar perdendo tempo configurando servidor web é um peso tirado das costas, pois muitas vezes é uma tarefa chata para devs, tudo que preciso fazer é colocar um proxy reverso na ponta, e para isso minha preferência é o haproxy e alguns outros uso a própria cloudflare. Temos que propagar essa modernização das aplicações php entre os devs, para mudar esse (pré-)conceito que a galera tem, que muitos falam que o php já morreu, php é ruim, php é linguagem do passado e etc, precisamos mostrar que o php está muito evoluído. :)

[@DiasDeDev]

Opa, esse comentário deve ter se perdido sim. Eu até tenho uma palestra sobre o tema. Vou pensar em como posso trazer isso num formato de vídeo mais curto. Valeu demais pela dica.

[@cedroigor]

Mano, teu comentário é de um ano atrás e eu nao sabia dessas coisas kkk. Eu ja tenho iamgens docker de nginx prontas pra cada tipo de projeto q vou subir e sim, é mto chato. Vou dar uma olhada nessas coisas, vlw!!

[@matheusrocate]

Muito bem explicado.

[@DiasDeDev]

Que bom que gostou

[@vanivilis]

Tem alguns anos que eu utlizo Nchan com Nginx, uma mão na roda, pois é pub/sub e funciona com EventSource.

[@BrandevTech]

Gostei heim! Parabéns. Tô pensando em aplicar essa solução pra ler o BD e enviar a info condicionada ao resultado dessa leitura... Mas não sei se isso poderia sobrecarregar o SQL 🤔

[@bitpickle]

Se precisa utilizar comunicação em tempo real, bancos de dados relacionais não são a melhor opção. Mas respondendo a questão: você vai ter um "endpoint" emitindo os eventos, e vários clients escutando o mesmo evento, recebendo a mesma mensagem (pelo menos é o que eu vejo como ideal). Independente da quantidade de clients, o acesso ao banco seria o mesmo (1 a cada X segundos, por exemplo). Caso precise de respostas personalizadas para cada consumidor da sua mensagem, talvez WebSockets seja uma opção melhor, simplesmente por ser bi-direcional. No exemplo do Vinicius, o loop infinito que ele criou possivelmente está bloqueando a thread e isso pode pendurar outras requisições enquanto estiver em execução. Acho que isso, se não for feito do jeito certo, pode afetar mais a escala do seu servidor do que o acesso ao banco de dados.

[@BrandevTech]

@@bitpickle Amigo. Valeu muito pelo retorno. Acho que destravou as ideias aqui, kkkk. Pensando bem vou resolver meu problema até de forma mais direta vinculando o envio do evento no momento do update. Show demais isso!

[@idontsleep777]

nome fico muito bom parabens, canal massa demais

[@DiasDeDev]

:-D

[@marceloramos385]

Top demais... e muito simples, achei q ia ser um mega código, obrigado mesmo Dias, a cada dia aprendo mais com vc, tanto no KZbin quanto na Alura kkkk

[@DiasDeDev]

Que bom que tenho sido útil, Marcelo. :-D

[@wilsonsgomes]

Esse é aquele vídeo que voce clica no like, confere pra ver se deu like mesmo, e depois clica em SALVAR pra ter sempre a mão. Top demais!

[@DiasDeDev]

Valeu demais, Wilson!

[@wilsonsgomes]

No meu caso não estava funcionando, e quando expirava o tempo de execução, aí retornava todos os eventos de uma vez só. Aí eu coloquei: ob_end_flush(); flush(); Dentro do loop, logo após o " ", então funcionou perfeitamente. Estou executando no PHP 7.4, com Apache, dentro de um Container Docker.

[@DiasDeDev]

Boa. Aqui eu explico por alto sobre buffer de saída e o que é esse flush: dias.dev/2020-11-03-wraper-de-streams-php/

[@netoti3311]

ajudou aqui estava quebrando a cabeça

[@maydana.programador]

First!?

[@DiasDeDev]

Uhul! Espero que seja útil aí pra você. :-D

[@LuizEduardo-ke3be]

Que conteúdo brabo! 🤌🏽✨️

[@DiasDeDev]

Que bom que curtiu, Luiz. :-D

[@centertreinamentos]

Obrigado pelo vídeo. Vai me ajudar muito aqui. Tenho um sistema que recebe pedidos online e fiz com javascript fazendo chamadas no servidor. Agora o servidor mandando direto para o navegador em php ficou nota 1000. Vou implementar aqui. Obrigado mais uma vez.

[@vitalvesneto]

Minha única insatisfação aqui é: Não poder dar mais de um like! Sensacional!

[@DiasDeDev]

heheheh Muito obrigado! :-D

[@developerjs-jr8237]

Bom dia Vinicius. Sempre trazendo conteúdos interessantes e importantes, parabéns pela didática.

[@DiasDeDev]

Opa, muito obrigado! :-D

[@Yukitocyborg]

Eu tava querendo saber sobre isso esses dias, pra fazer um sistema de notificação e tals, não sabia que era tão simples, vídeo excelente como sempre!!

[@DiasDeDev]

Bem tranquilo, né!? Usando ferramentas ao invés de fazer "na unha" assim fica mais fácil ainda. :-D

[@jeffegiovani]

Tô sem palavras, eu não conhecia isso ainda. Preciso estudar com urgência!

[@DiasDeDev]

Maneiro, né!?

[@Barbara-st2fs]

você explica muito bem. Obrigada por compartilhar seu conhecimento conosco.

[@DiasDeDev]

Muito obrigado, Barbara. Que bom que está gostando.

[@marcelomsmms]

Sensacional! Obrigado por compartilhar

[@DiasDeDev]

Que bom que gostou! :-D

[@hnqca]

Que vídeo maravilhoso!! Muito obrigado!

[@DiasDeDev]

Que bom que gostou. :-D

[@niltonduarte3531]

Eu já tinha comentado no seu vídeo sobre mensageria perguntando se eu podia usar RabitMQ da mesma forma que a documentação do Ratchet usa ZeroMQ e você me sugeriu o erver-sent events. Mas não vi a documentação na descrição que você falou em 11:03.

[@DiasDeDev]

Erro meu, Nilton. Já adicionei a doc na descrição. Mas segue aqui também: developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

[@niltonduarte3531]

@@DiasDeDev Obrigado!

[@rotognin]

Eita! Isso é muito útil em alguns casos e muito fácil de se implementar! Obrigado 👍

[@DiasDeDev]

Que bom que curtiu, Rodrigo. :-D

[@brunobinera432]

Caraca que top, esse canal só tem conteúdo brabo em, parabéns

[@DiasDeDev]

Que bom que está curtindo, Bruno. :-D

[@RodrigoMedeirosBrazil]

Mais um conteúdo top! Aqui é fonte infinita de conhecimento!

[@DiasDeDev]

Heheheh Que bom que tem curtido, Rodrigo. :-D

Bom demais, parabéns Vinicius!

[@DiasDeDev]

Valeu, Mateus! Tmj!

[@rafaelsilveira4392]

O que você acha desse código para retornar atualizações no banco de dados? Sobrecarrega?

[@DiasDeDev]

Sem mais informações, impossível impossível opinar. 😅

[@rootraiz8108]

Obrigado pelo conteudo maravilhoso.

[@rootraiz8108]

Diretamente de mocambique

[@brunoggdev6305]

Que bacana cara, não sabia dessa, muito interessante (e de quebra a explicação sobre o servidor embutido do PHP me fez notar o pq de uma requisição de teste http pra dentro do meu próprio servidor não estava funcionando. Provavelmente é por ser o servidor embutido né?)

[@DiasDeDev]

Que bom que curtiu, Bruno! Sim, o servidor embutido do PHP só lida com uma requisição por vez, infelizmente.

[@henriquealves9879]

Fantático esse recurso!

[@DiasDeDev]

Bem maneiro, né!? :-D

[@marcelgsantos]

Mais uma dica excelente. Parabéns pelo conteúdo! :)

[@DiasDeDev]

Opa, que honra, mestre. Que bom que gostou. 🤩

[@wellingtoncapoia]

Cara e uma duvida, isso pesa? tanto pro navegador do cliente quanto pro servidor que esta servindo os eventos? Pergunto porque nunca ouvi falar, e me parece ser uma solução muiito simples pra notificacões.

[@DiasDeDev]

É uma conexão TCP como qualquer outra. Tem seu peso, claro, mas nada absurdo não. :-) Se você tiver milhões de conexões abertas, seu servidor precisa aguentar isso, claro. Pra continuar com essas abertas enquanto recebe outras. Mas via de regra, isso não gera muito gargalo não. :-D

[@JoaoPauloPVillela]

Parabéns super conteúdo, fiquei com uma dúvida, tem algumas forma de fazer com que apenas com a mudança de status essa começa a executar, pensei em algumas formas porém pouco elegante, há uso o nosso amigo Laravel, desde já muito obrigado

[@DiasDeDev]

Não entendi sua dúvida, João Paulo. Pode reformular?

[@JoaoPauloPVillela]

@@DiasDeDev Não gostaria de ficar fazendo consulta no banco todas às vezes, queria que apenas quando um evento fosse finalizado ele executasse. Pensei em fazer por cache e ele ficar verificando se esse cache está preenchido, ai quando ele ficar ai sim executa, mas achei muito "feio" tem outra forma de fazer com que ele seja processando apenas quando um evento for disparado?

[@DiasDeDev]

@@JoaoPauloPVillela , não faz sentido você ficar verificando a fonte. Você tem que reagir a algum evento. Não é pra ficar consultando o banco ou cache. É pra você enviar esse SSE quando você receber algum tipo de mensagem no seu servidor.

[@GuilhermeXavier883]

Video massa, mas tenho uma duvida como faço pra mandar request header pelo evento ?

[@DiasDeDev]

Cada evento é um evento, não uma resposta nova. rsrs Os cabeçalhos já foram enviados. Não entendi sua ideia. Acho que sua pergunta caiu aqui: xyproblem.info/

[@GuilhermeXavier883]

@@DiasDeDev a questão era pra mandar o payload e headers somente uma vez mesmo no handshake, mas consegui resolver usando uma lib da microsoft @microsoft/fetch-event-source, mas valeu pela sua resposta

[@marcaosax4552]

Fala Vinicius, beleza? parabéns pelo vídeo, muito massa mesmo. Queria sabe contigo se seria uma boa usar Server-Sent Events para monitorar o meu server por exemplo, acompanhar infos como espaço em disco, memória ram usada, tráfego na rede etc, em tempo real

[@DiasDeDev]

Eu, particularmente, usaria uma ferramenta já existente pra isso. Mas se você quer criar sua ferramenta, SSE são sim a técnica ideal.

[@franklin71381]

Não tava funcionando com loop, então resolvi mater a lógica porém sem o while(true) e adicionei "retry: 1000 " no arquivo sse.php e pegou igual no vídeo

[@rafaelbodet]

ainda sim o meu não funciona. só que agora o erro é no JS

[@franklin71381]

Coloquei em produção e funcionou durante algumas horas, a aplicação tem uns 100 visitantes por hora e ta na aws. Depois de algumas horas em produção tudo começou a ficar extremamente lento, fui até verificar se estava sofrendo ddos ou algo do tipo, mas não...

[@DiasDeDev]

Grandes chances do seu servidor web estar configurado para ter um número máximo de conexões simultâneas. Lembre-se que com SSE, sua conexão HTTP vai ficar aberta. Suas configurações de produção precisam se adequar a isso. ;-)

[@posinfo]

Eu conseguiria fazer substituição do Ajax por essa técnica?

[@Lucas-mu5no]

provavelmente você está falando de pooling com Ajax, se for o caso, sim, poderia.

[@posinfo]

@@Lucas-mu5no e como daria pra fazer um clique em um botão e a resposta ser mostrada na tela

[@Lucas-mu5no]

@@posinfo Se há um clique de botão então há uma ação do usuário. O SSE não é pra esse cenário, do que jeito que tu falou é como se o usuário estivesse solicitando algo pro servidor de forma ativa, pra isso esse as requests HTTP já (com ou sem ajax). O SSE serve pro servidor enviar informações pro cliente (navegador) sem que este tenha que realizar novas requisições. Cenários para isso são atualização de flutuações de moedas, clima, jogos de futebol etc. Pro usuário não precisar ficar toda hora atualizando a página pra pegar informação nova, com o SSE o próprio servidor notificaria o navegador de que há informação nova.

[@flaviovivinho4406]

Muito bom, parabéns pelo conteúdo. Estou desenvolvendo uma aplicação que preciso de resposta em tempo real para alguns sensores (monitoramento com sensores) e essa ideia será bem útil. Mas ficou um dúvida. No caso, o JS no cliente fica rodando direto com o navegador dele aberto para fazer as chamadas no servidor, correto? Assim, é o JS no cliente que faz as requisições, isso? Se fechar o navegador ou o JS parar todo processo também para, correto?

[@DiasDeDev]

O JS faz uma única requisição e essa conexão fica aberta. As mensagens são enviadas pelo servidor, não pelo cliente. Ao fechar o navegador a conexão é fechada.

[@flaviovivinho4406]

@@DiasDeDev Entendi. Obrigado.

[@insider4441]

digamos que tenho um site onde armazeno 'moedas' virtuais, esse método seria o mais eficiente para manter essas 'moedas' atualizadas para o client em tempo real ?

[@DiasDeDev]

Se você não precisa que o client envie informações em tempo real também, sim.

[@insider4441]

@@DiasDeDev entendi, no caso seria só pra manter as 'moedas' do client em tempo real. Outro cenário por exemplo, seria de pagamento, por exemplo pix. assim que for aprovado ele fazer o redirecionamento, correto ?

[@cssgabriel]

Muito bom!!

[@DiasDeDev]

Que bom que curtiu. :-D

[@lucasamazonas6691]

Cara, que incrível!

[@DiasDeDev]

Opa, que bom que curtiu, Lucas. 😁

[@MundoDoSonhos]

Top, estava precisando de algo assim

[@DiasDeDev]

Opa, que bom que vai ser útil. :-D

[@isaacborges1619]

Só me tira uma dúvida, isso não gera uma sobrecarga no servidor não ? Pq cara seria muito massa isso, eu faço com ajax, mas isso seria muito melhor.

[@DiasDeDev]

Pelo contrário. Pode aliviar a carga do servidor em alguns casos se você fica toda hora criando conexões. Nesse caso ele cria a conexão e ela fica aberta.

[@isaacborges1619]

Faz um vídeo buscando alguma coisa do banco de dados. Seria ótimo para ajudar a gente aqui.

[@WillianMauricio-p9h]

Testei em uma aplicação laravel e não obtive sucesso. Acredito que seja alguma configuração do PHP, pois quando faço a chamada do path no EventSource a requisição fica em aberto e nunca retorna nada. Detalhe já testei fazer ob_end_flush(); e flush(); Testei com php puro, sem framework e realmente funcionou. Talvez seja alguma coisa do Laravel. Saberia me informa? Descobri que o real problema está no "sleep(1)", se eu remover essa linha no código, o SSE funciona, porém explode várias informações em curto período de tempo, e eu preciso desse sleep, para não sobrecarregar os servidores. Algum motivo para esse sleep ser o causador no problema?

[@DiasDeDev]

Como você fez? Usou StreamedResponse?

[@WillianMauricio-p9h]

​@@DiasDeDev Sim, utilizei o StreamedResponse. Basicamente, o que eu fiz foi criar um echo "data: VALOR ", posteriormente ob_end_flush(); e flush() e por fim o sleep(1), isso tudo em um while (true). Também tentei não utilizando o StreamedResponse, definindo apenas as headers necessárias, mas também não obtive sucesso.

[@luigiets]

interessante, mas tenho uma duvida essa pagina pararia com max_execution_time do php? Outra questão se cair a conexão o listener tentaria refazer a conexão? Uma pergunta se eu fizesse uma conexão com o banco com o código para trazer um resultado de pedido de atualizar a pagina, isso daria muito processo ao meu servidor? Desculpa a quantidade de perguntas que achei interessante isso e estava precisando de uma forma de fazer isso, iria tentar socket só que o meu servidor atual não é configurado por mim e por isso não conseguiria adicionar um serviço com um php em uma porta. vídeo

[@DiasDeDev]

> essa pagina pararia com max_execution_time do php? Sim. Basta remover a limitação para essa execução > Outra questão se cair a conexão o listener tentaria refazer a conexão? Sim. Passando no evento a informação "retry" você informa quantos milissegundos o cliente precisa esperar antes de tentar a reconexão > Uma pergunta se eu fizesse uma conexão com o banco com o código para trazer um resultado de pedido de atualizar a pagina, isso daria muito processo ao meu servidor? Não entendi nada dessa pergunta. rsrsrs

[@luigiets]

@@DiasDeDev obrigado por responder dei uma olhada aqui, seu vídeo foi muito instrutivo e você me ajudou muito

[@danidaniel1161]

Esse método é menos "custoso" do que ficar fazendo requisições de tempos em tempos?

[@DiasDeDev]

Sim. Abrir uma conexão possui custos (que são ainda maiores com HTTPS). Nesse caso a conexão é aberta uma única vez e fica assim até não ser mais necessária. Isso sem contar o fato de que fazer requisições de tempos em tempos não permite trabalho em tempo real. Há aplicações que precisam que o evento seja enviado realmente em tempo real.

[@antoniocosta7565]

Que top

[@DiasDeDev]

Que bom que curtiu, Antonio. :-D

[@natanaelvilaca]

Isso pode desgastar meu servidor?

[@DiasDeDev]

Software não se desgasta, Natanael. Não entendi sua pergunta. rsrsrs

[@natanaelvilaca]

Ah desculpa, talvez usei a expressão errada, então para ser mais claro pergunto se esse recurso pode impactar significamente na memória de um servidor impactando no desempenho. Pois tenho um servidor contratado não tão bom e trabalho orientado em otimização sempre.

[@darcio28]

top de +

[@DiasDeDev]

Que bom que curtiu, Darcio. :-D

[@luizmagao]

Vinícius você aconselha usar bate bapo com ele?

[@DiasDeDev]

Não é questão de aconselhar. Não faz sentido. SSE não é comunicação bi-direcional. Pra isso você usa websocket. Já tem vídeo sobre isso, exatamente criando um chat, no canal. :-)

[@rafabl7]

👏🏼👏🏼👏🏼

[@20toninho]

mais alguem ouviu ele falar "me traz dificuldades anais" ? sorry, but i had to ask kkkkkkkkkkk

[@DiasDeDev]

Que isso, cara? Haushasuhasuashusah

[@PauloSantosk]

Legal o vídeo, mas um loop infinito em um servidor de aplicação real seria facilmente derrubado em serviços de hospedagem nacional. Além do mais, caso se adicione complexidade no serviço, como uma consulta no banco de dados por exemplo (processamento e IO) o cenário piora ainda mais. Como o PHP isola as suas threads, não dá pra criar nada muito moderno com esse tipo de tecnologia, infelizmente.

[@DiasDeDev]

Paulo, você definitivamente não entendeu a ideia. rsrsrs > um loop infinito em um servidor de aplicação real seria facilmente derrubado em serviços de hospedagem nacional Se você usa um serviço que não suporta conexões persistentes, não é uma limitação da tecnologia/linguagem, e sim da sua hospedagem. Mas eu duvido que isso realmente aconteça. > Como o PHP isola as suas threads, não dá pra criar nada muito moderno com esse tipo de tecnologia, infelizmente. Essa afirmação não faz o menor sentido. Você pode ter o PHP rodando exatamente como um node da vida se quiser. E o vídeo é sobre SSE, não sobre PHP. rsrsrs

[@PauloSantosk]

@@DiasDeDev Então, acho que entendi bem sim, mas talvez não tenha conseguido me expressar da maneira correta no meu comentário. Quando digo sobre criar algo moderno, digo utilizando dados compartilhados na memória do servidor da aplicação, sem usar de I/O, como é possível no Node/Java. Justamente porque não há meio de compartilhar dados entre diferentes sessões com PHP que não seja passando pelo disco do servidor (ou pelo banco de dados ou por algum arquivo salvo em disco, como no caso das sessões por exemplo). Em Node/Java por exemplo, é possível compartilhar um objeto em memória(RAM) e servir esse objeto, inclusive com SSEvents(caso seja de interesse) e, isso faz toda diferença quando se pensa na utilidade de usar alguma coisa em tempo real. Um cenário comum, seria escutar quando algum registro é feito nalguma tabela do banco de dados para notificar os "peers", com Java/Node, é possível interceptar a requisição de entrada dos dados e o script de SSEvent ser notificado sem lidar com I/O, tudo em memória, já no PHP (justamente pela sua característica de isolamento de threads), isso é inviável sem alguma gambiarra que onere os recursos do servidor. Posto isso, reitero que essa ferramenta perde o brilho, pelo menos no quesito de utilidade, por fator limitante do PHP. Sobre os servidores, concordo, a limitação se dá por parte deles, pois qualquer servidor com Node, faz com que o uso de Sockets ou até mesmo o de SSEvents fazer mais sentido para implementar acessos em tempo real, levando em conta o escalonamento da aplicação e no montante de recurso queimado para manter esse tipo de serviço de forma funcional.

[@DiasDeDev]

Mas por que você acha que isso não seria possível com PHP? É perfeitamente possível (e até fácil) ter esse comportamento.

[@PauloSantosk]

@@DiasDeDev Aí fui surpreendido, falta de conhecimento meu então. Como você faz para compartilhar dados entre duas sessões (dois ou mais usuários) do PHP sem utilizar de acesso ao disco (banco de dados, arquivos ou php session)? Tem como definir um objeto em memória que pode ser acessado por todas as sessões? Essa é uma das coisas do PHP que considero como limitação, com Java/Node, eu consigo inclusive ter threads ativas em segundo plano. Mas é como eu disse, talvez seja falta de conhecimento de minha parte.

[@ClaytonBarbosaFilho]

@@PauloSantosk Não, você não entendeu mesmo, ele ja falou o video nao é sobre o PHP, esse video aborda uma tecnologia só isso, nao cabe discussão se é a melhor ou pior ferramenta do mundo, o objetivo do video nao é esse, e se voce quer mostrar seus conhecimentos crie o seu canal e faça videos assim voce pode demonstrar tudo que sabe, em vez de ficar querendo dar aula para o professor, esses tipos de comentarios nao agregam em nada, só desmotiva quem gera conteudo, e sua critica é contra o php o Dias nao tem nada haver com isso.

[@cacacobra]

Estranho, ao reproduzir seu código ele não roda, testei um exemplo de outro site e vi que essa parte do evento "event" buga o código, mesmo o Javascript não precisando dele pra rodar.