[Resolvido] atualizar a cada 1 segundo select

[manoaj 12]

pessoal eu tenho um select e queria atualizar o resultado dele a cada 1segundo sem atualizar toda pagina.

 

<?php
   $postagem = mysql_query("SELECT *  FROM c_posts")or die(mysql_error());
   $postagems_users = mysql_fetch_array($postagem);

?>
<div id="noticia"><?php echo $postagems_users['postagem']; ?></div>

 

queria atualizar o resultado do echo dentro dessa div a cada 1segundo,

ou toda vez que for inserido um registro seja mostrado na hora.

[Guilherme Oderdenge 42]

Olá, manoaj. Tudo bem? Espero que sim.

 

Bom, com PHP você não consegue fazer essa "atualização" em tempo real. Isso acontece porque é uma necessidade do cliente que algo visualizável seja atualizado de tempos em tempos. Falei em cliente, então qual é a solução? Javascript! É, isso mesmo, Javascript.

 

Com o Javascript você consegue fazer com que o navegador faça uma requisição de tempos em tempos, e então, graças a esta técnica, é possível com que você atualize o select a cada 1 segundo. Mas... Calma aí! A necessidade é, necessariamente, que tenha este intervalo de tempo? Se sim, apresento-lhe o short polling.

 

O short polling é uma técnica — como já falado — Javascript que fará com que o cliente faça uma requisição para o servidor de tempos em tempos. Se você não sabe, a requisição que estou falando é a mesma que você faz quando acessa uma página: solicita ao servidor que entregue o produto de um script em questão — geralmente o script que você pôs na URL.

 

O short polling irá solucionar o seu problema. Porque ele é exatamente o que você quer. Agora, façamos um levantamento:

• Vantagem: É simples de fazer e não exige recursos do servidor (se o tempo das requisições for alto);
  
• Desvantagem: Péssimo — isso mesmo, p é s s i m o — se você irá trabalhar com vários clientes e várias requisições simultaneamente. Na verdade, até mesmo uma requisição pode se tornar um problema à médio prazo.
  

Se humanizarmos o short polling, teremos isso:

(0 segundos) Cliente -> requisita select para o -> Servidor

(0 segundos) Cliente <- servidor responde "null" porque não há nenhuma atualização para <- Servidor

(1 segundo) Cliente -> requisita select para o -> Servidor

(1 segundo) Cliente <- servidor responde "null" porque não há nenhuma atualização para <- Servidor

(2 segundos) Cliente -> requisita select para o -> Servidor

(2 segundos) Cliente <- servidor responde "null" porque não há nenhuma atualização para <- Servidor

(3 segundos) Cliente -> requisita select para o -> Servidor

(3 segundos) Cliente <- servidor responde "null" porque não há nenhuma atualização para <- Servidor

(4 segundos) Cliente -> requisita select para o -> Servidor

(4 segundos) Cliente <- servidor responde "null" porque não há nenhuma atualização para <- Servidor

(5 segundos) Cliente -> requisita select para o -> Servidor

(5 segundos) Cliente <- servidor retorna o resultado, porque agora há <- Servidor

Se você parar para pensar, o processo acima é chato e cansativo. Imagina eu ficar perguntando para você, de 1 em 1 segundo, se você tem alguma novidade para me contar. É meio lógico que quando você tiver algo para contar, irá me contar, não é mesmo? E ah, cuidado! Empresas de hospedagem e clientes não são magnânimos o suficiente para tolerar quedas do servidor, okay? Então tente desde cedo arquitetar bem a sua estrutura.

 

A solução mais segura, sólida, eficiente e de melhor performance para atender a sua necessidade é utilizando métodos mais complexos — sim, mais complexos! Para quem está começando, conseguir abstrair o conceito de uma aplicação em tempo real bem feita pode ser exaustivo. Mas é para isso que estamos aqui: lhe ajudar.

 

Como já falado lá no início da minha resposta, você precisa de Javascript: server-side ou client-side — aí é com você.

 

Se tem a necessidade de uma estrutura mais trivial mas que dê conta do recado, vá de PHP utilizando a técnica long polling em Javascript. Adianto que esta técnica é eficiente à curto prazo. Digo isso porque ela pode ser uma pedra no caminho quando a sua aplicação começar a pairar algo por volta das 1000 (mil) requisições simultâneas e paralelas ou não.

 

Long polling e short polling... Ué? Mas o que diabos são essas "coisas"? Bom, são técnicas de server push ou tecnologias push. O server push tem a filosofia assíncrona de trabalhar, que reflete a transmissão de informações em tempo real. Dentro das tecnologias push temos técnicas que vão além do long ou short polling — tal como o Comet (ou, QUEM SABE, AJAX reverso — onde o servidor teoricamente "responde" algo ao cliente).

 

Como já vimos o short polling, explicarei o long polling. De forma humana, teremos o seguinte:

(0 segundos) Cliente -> requisita select para o -> Servidor

(17 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(17 segundos) Cliente -> requisita select para o -> Servidor

(44 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(44 segundos) Cliente -> requisita select para o -> Servidor

(126 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

Pergunto: conseguiu notar a diferença? O cliente pergunta. O servidor somente responde QUANDO tiver algo para responder, e então o cliente requisita de novo algo para o servidor. E o que acontece quando uma requisição é re-estabelecida? Ela é aberta e mantida assim até que o servidor responda com alguma coisa. Veja:

No exemplo acima, uma requisição é feita; o servidor trabalha em cima dela e responde ao cliente (browser); com a resposta em mãos, o cliente faz uma nova requisição e... Voi là! Agora você tem long polling.

 

Mas, até onde o long polling é viável? Como eu disse antes, ele é viável à "curto prazo". Isso porque essas requisições novas que são feitas cada vez que o servidor responde também pesam. Imagine você se sua aplicação tem várias atualizações por minuto e há várias requisições simultaneamente... Poxa, o negócio pode virar quase um short polling, você não acha?

 

Antes de avançarmos no assunto, o Beraldo escreveu este guia sobre long polling. Além dele, o Andrey escreveu também este e este artigo que irão lhe ajudar — e muito — caso o long polling seja suficiente para você.

 

Agora sim, vamos avançar?

 

Agora é a vez do Node

Se você realmente deseja uma estrutura excelente e destinada a aplicações em tempo real, introduzo-lhe o NodeJS. Ele é o Javascript server-side que você pode ter estranhado eu ter mencionado anteriormente.

 

A proposta dele é trabalhar baseado em eventos — e de maneira assíncrona, claro — e, na maioria dos casos (ou todos), com aplicações em tempo real. Ele é uma plataforma promissora que opera sobre a linguagem Javascript (ta aí uma dica para você ganhar dinheiro no futuro!) lançado em 2009, pela Joyent, Inc.

 

Com Node, nós podemos fazer isso:

(0 segundos) Cliente -> requisita select para o -> Servidor

(3 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(6 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(12 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(24 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(32 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(33 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(35 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

(41 segundos) Cliente <- há uma atualização no banco e o select trabalha com a tabela atualizada, então o servidor responde <- Servidor

Mhmmmm... Consegue visualizar o que aconteceu? Com apenas uma requisição é possível trazer toda e qualquer resposta que o servidor tenha para você. Capitou!??! Quando algo atualizar no banco, envie para o cliente! Simples assim!

 

Essa estrutura, meu rapaz, lhe dá uma economia absurda de recursos e irá reduzir consideravelmente o tráfego de dados que ocorre (ou ocorrerá) na sua aplicação.

 

Lhe apresentei a solução, certo? Agora cabe a você decidir o que é melhor para você e correr atrás. Vou te deixar algumas referências de NodeJS, okay? Qualquer dúvida estou à disposição!

 

• Introdução ao NodeJS (em português)
  
• Usando NodeJS para criar uma aplicação em tempo real (em inglês)
  

Por fim, deixo você com este infográfico:

 

Espero ter te ajudado.

Boa sorte nos estudos e abraço! :thumbsup:/>

[manoaj 12]

Olá, manoaj. Tudo bem? Espero que sim.

 

Bom, com PHP você não consegue fazer essa "atualização" em tempo real. Isso acontece porque é uma necessidade do cliente que algo visualizável seja atualizado de tempos em tempos. Falei em cliente, então qual é a solução? Javascript! É, isso mesmo, Javascript.

 

Com o Javascript você consegue fazer com que o navegador faça uma requisição de tempos em tempos, e então, graças a esta técnica, é possível com que você atualize o select a cada 1 segundo. Mas... Calma aí! A necessidade é, necessariamente, que tenha este intervalo de tempo? Se sim, apresento-lhe o short polling.

 

O short polling é uma técnica — como já falado — Javascript que fará com que o cliente faça uma requisição para o servidor de tempos em tempos. Se você não sabe, a requisição que estou falando é a mesma que você faz quando acessa uma página: solicita ao servidor que entregue o produto de um script em questão — geralmente o script que você pôs na URL.

 

O short polling irá solucionar o seu problema. Porque ele é exatamente o que você quer. Agora, façamos um levantamento:

• Vantagem: É simples de fazer e não exige recursos do servidor (se o tempo das requisições for alto);
  
• Desvantagem: Péssimo — isso mesmo, p é s s i m o — se você irá trabalhar com vários clientes e várias requisições simultaneamente. Na verdade, até mesmo uma requisição pode se tornar um problema à médio prazo.
  

Se humanizarmos o short polling, teremos isso:

 

Se você parar para pensar, o processo acima é chato e cansativo. Imagina eu ficar perguntando para você, de 1 em 1 segundo, se você tem alguma novidade para me contar. É meio lógico que quando você tiver algo para contar, irá me contar, não é mesmo? E ah, cuidado! Empresas de hospedagem e clientes não são magnânimos o suficiente para tolerar quedas do servidor, okay? Então tente desde cedo arquitetar bem a sua estrutura.

 

A solução mais segura, sólida, eficiente e de melhor performance para atender a sua necessidade é utilizando métodos mais complexos — sim, mais complexos! Para quem está começando, conseguir abstrair o conceito de uma aplicação em tempo real bem feita pode ser exaustivo. Mas é para isso que estamos aqui: lhe ajudar.

 

Como já falado lá no início da minha resposta, você precisa de Javascript: server-side ou client-side — aí é com você.

 

Se tem a necessidade de uma estrutura mais trivial mas que dê conta do recado, vá de PHP utilizando a técnica long polling em Javascript. Adianto que esta técnica é eficiente à curto prazo. Digo isso porque ela pode ser uma pedra no caminho quando a sua aplicação começar a pairar algo por volta das 1000 (mil) requisições simultâneas e paralelas ou não.

 

Long polling e short polling... Ué? Mas o que diabos são essas "coisas"? Bom, são técnicas de server push ou tecnologias push. O server push tem a filosofia assíncrona de trabalhar, que reflete a transmissão de informações em tempo real. Dentro das tecnologias push temos técnicas que vão além do long ou short polling — tal como o Comet (ou, QUEM SABE, AJAX reverso — onde o servidor teoricamente "responde" algo ao cliente).

 

Como já vimos o short polling, explicarei o long polling. De forma humana, teremos o seguinte:

 

Pergunto: conseguiu notar a diferença? O cliente pergunta. O servidor somente responde QUANDO tiver algo para responder, e então o cliente requisita de novo algo para o servidor. E o que acontece quando uma requisição é re-estabelecida? Ela é aberta e mantida assim até que o servidor responda com alguma coisa. Veja:

No exemplo acima, uma requisição é feita; o servidor trabalha em cima dela e responde ao cliente (browser); com a resposta em mãos, o cliente faz uma nova requisição e... Voi là! Agora você tem long polling.

 

Mas, até onde o long polling é viável? Como eu disse antes, ele é viável à "curto prazo". Isso porque essas requisições novas que são feitas cada vez que o servidor responde também pesam. Imagine você se sua aplicação tem várias atualizações por minuto e há várias requisições simultaneamente... Poxa, o negócio pode virar quase um short polling, você não acha?

 

Antes de avançarmos no assunto, o Beraldo escreveu este guia sobre long polling. Além dele, o Andrey escreveu também este e este artigo que irão lhe ajudar — e muito — caso o long polling seja suficiente para você.

 

Agora sim, vamos avançar?

 

Agora é a vez do Node

Se você realmente deseja uma estrutura excelente e destinada a aplicações em tempo real, introduzo-lhe o NodeJS. Ele é o Javascript server-side que você pode ter estranhado eu ter mencionado anteriormente.

 

A proposta dele é trabalhar baseado em eventos — e de maneira assíncrona, claro — e, na maioria dos casos (ou todos), com aplicações em tempo real. Ele é uma plataforma promissora que opera sobre a linguagem Javascript (ta aí uma dica para você ganhar dinheiro no futuro!) lançado em 2009, pela Joyent, Inc.

 

Com Node, nós podemos fazer isso:

 

Mhmmmm... Consegue visualizar o que aconteceu? Com apenas uma requisição é possível trazer toda e qualquer resposta que o servidor tenha para você. Capitou!??! Quando algo atualizar no banco, envie para o cliente! Simples assim!

 

Essa estrutura, meu rapaz, lhe dá uma economia absurda de recursos e irá reduzir consideravelmente o tráfego de dados que ocorre (ou ocorrerá) na sua aplicação.

 

Lhe apresentei a solução, certo? Agora cabe a você decidir o que é melhor para você e correr atrás. Vou te deixar algumas referências de NodeJS, okay? Qualquer dúvida estou à disposição!

 

• Introdução ao NodeJS (em português)
  
• Usando NodeJS para criar uma aplicação em tempo real (em inglês)
  

Por fim, deixo você com este infográfico:

 

Espero ter te ajudado.

Boa sorte nos estudos e abraço! :thumbsup:/>

POw cara vlw orbigado pela aula kkkk vou estudar as opções que você me deu :D :clap:

[Guilherme Oderdenge 42]

Disponha. Bons estudos! :joia:

[Sandro Matos 17]

phoda msm gostei :clap: