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. :)
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.
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!!
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.
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 RUclips quanto na Alura kkkk
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.
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 🤔
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.
@@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!
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é?)
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
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.
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
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.
É 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
@@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.
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?
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.
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
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/
@@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
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...
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. ;-)
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 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?
@@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.
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 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 ?
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.
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.
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.
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
> 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
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. :-)
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.
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.
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
@@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 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.
@@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.
Não fazia ideia que era assim, vivendo e aprendendo com Vinicius Dias! =D
Valeu demais pela moral de sempre, Guilherme.
Que bom que tem gostado do conteúdo. :-D
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. :)
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.
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!!
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.
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/
ajudou aqui estava quebrando a cabeça
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 RUclips quanto na Alura kkkk
Que bom que tenho sido útil, Marcelo. :-D
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.
Bom dia Vinicius.
Sempre trazendo conteúdos interessantes e importantes, parabéns pela didática.
Opa, muito obrigado! :-D
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!!
Bem tranquilo, né!? Usando ferramentas ao invés de fazer "na unha" assim fica mais fácil ainda. :-D
você explica muito bem. Obrigada por compartilhar seu conhecimento conosco.
Muito obrigado, Barbara. Que bom que está gostando.
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 🤔
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.
@@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!
First!?
Uhul!
Espero que seja útil aí pra você. :-D
Tem alguns anos que eu utlizo Nchan com Nginx, uma mão na roda, pois é pub/sub e funciona com EventSource.
Eita! Isso é muito útil em alguns casos e muito fácil de se implementar!
Obrigado 👍
Que bom que curtiu, Rodrigo. :-D
Mais um conteúdo top! Aqui é fonte infinita de conhecimento!
Heheheh
Que bom que tem curtido, Rodrigo. :-D
Que vídeo maravilhoso!! Muito obrigado!
Que bom que gostou. :-D
Tô sem palavras, eu não conhecia isso ainda. Preciso estudar com urgência!
Maneiro, né!?
Que conteúdo brabo! 🤌🏽✨️
Que bom que curtiu, Luiz. :-D
Sensacional! Obrigado por compartilhar
Que bom que gostou! :-D
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!
Valeu demais, Wilson!
Bom demais, parabéns Vinicius!
Valeu, Mateus! Tmj!
Caraca que top, esse canal só tem conteúdo brabo em, parabéns
Que bom que está curtindo, Bruno. :-D
Minha única insatisfação aqui é: Não poder dar mais de um like!
Sensacional!
heheheh
Muito obrigado! :-D
Fantático esse recurso!
Bem maneiro, né!? :-D
Mais uma dica excelente. Parabéns pelo conteúdo! :)
Opa, que honra, mestre. Que bom que gostou.
🤩
Obrigado pelo conteudo maravilhoso.
Diretamente de mocambique
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é?)
Que bom que curtiu, Bruno! Sim, o servidor embutido do PHP só lida com uma requisição por vez, infelizmente.
Cara, que incrível!
Opa, que bom que curtiu, Lucas. 😁
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
ainda sim o meu não funciona. só que agora o erro é no JS
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.
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
@@DiasDeDev Obrigado!
Muito bom!!
Que bom que curtiu. :-D
Top, estava precisando de algo assim
Opa, que bom que vai ser útil. :-D
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.
É 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
Que top
Que bom que curtiu, Antonio. :-D
O que você acha desse código para retornar atualizações no banco de dados? Sobrecarrega?
Sem mais informações, impossível impossível opinar.
😅
Eu conseguiria fazer substituição do Ajax por essa técnica?
provavelmente você está falando de pooling com Ajax, se for o caso, sim, poderia.
@@Lucas-mu5no e como daria pra fazer um clique em um botão e a resposta ser mostrada na tela
@@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.
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?
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.
@@DiasDeDev Entendi. Obrigado.
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
Eu, particularmente, usaria uma ferramenta já existente pra isso. Mas se você quer criar sua ferramenta, SSE são sim a técnica ideal.
Video massa, mas tenho uma duvida como faço pra mandar request header pelo evento ?
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/
@@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
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...
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. ;-)
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
Não entendi sua dúvida, João Paulo. Pode reformular?
@@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?
@@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.
top de +
Que bom que curtiu, Darcio. :-D
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 ?
Se você não precisa que o client envie informações em tempo real também, sim.
@@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 ?
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.
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.
Faz um vídeo buscando alguma coisa do banco de dados. Seria ótimo para ajudar a gente aqui.
Esse método é menos "custoso" do que ficar fazendo requisições de tempos em tempos?
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.
👏🏼👏🏼👏🏼
Isso pode desgastar meu servidor?
Software não se desgasta, Natanael. Não entendi sua pergunta. rsrsrs
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.
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
> 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
@@DiasDeDev obrigado por responder dei uma olhada aqui, seu vídeo foi muito instrutivo e você me ajudou muito
Vinícius você aconselha usar bate bapo com ele?
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. :-)
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.
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.
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
@@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.
Mas por que você acha que isso não seria possível com PHP? É perfeitamente possível (e até fácil) ter esse comportamento.
@@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.
@@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.
mais alguem ouviu ele falar "me traz dificuldades anais" ? sorry, but i had to ask kkkkkkkkkkk
Que isso, cara?
Haushasuhasuashusah