Qual o método mais utilizado para comunicação frontend / backend ?

[Jhon Paulo 7]

Olaá galera, minha pergunta é exatamente essa:

Qual o melhor método ou o mais usado para comunicação backend/frontend?

 

fiquei intrigado com isso pois comecei a fazer uma modelagem abstrata para buscar dados no db, e surgiu uma dúvida q ao meu ver deve ter pegado muitas pessoas de jeito: Como irei passar o trabalho bem feito para o frontend?

 

ou, como passarei uma parcela da responsabilidade do model(mvc) para ser tratada, via javascript, no lado cliente?

 

basicamente é isso.. espero que tenham entendido a pergunta :D

[Massaki 47]

Eu crio Views e Controllers totalmente diferentes para frontend e backend (com pouquíssimas excessões).

[Gabriel Heming 766]

Eu gostei de utilizar um parser, onde no front-end eram definidos os "nomes" das variáveis, diretamente no HTML e no back-end era definido qual o valor que seria colocado nessa variável.

 

Você já utilizou algum framework (Zend, Cake, CodeIgniter)? É interessante o uso deles para aprender na prática como funciona a separação de responsabilidade. Saber fazer, e entender como funciona, é muito melhor do que usar algo pronto, óbvio. Entretanto, na prática é muito mais fácil aprender.

 

Isso me lembrou de um exemplo do autor Roberto "UncleBob" Martin (não estou com o livro em mãos para escrever corretamente o que ele escreveu):

"Posso lhe ensinar o dia todo através cálculos e gráficos demonstrando a física exercida e lhe mostrar por A + B que é possível andar de bicicleta. Mas, mesmo assim, na primeira vez você vai cair."

[Jhon Paulo 7]

Massaki, eu fico muito na dúvida tipo assim: Eu fiz o model agora, daí fico na dúvida se vou mandar os dados via json, xml ou simples tags html, daí se estaria nos padrões do mercado atual eu fazer um return json_encode($pdo->fetchAll(PDO::FETCH_OBJ)); dai o js faria o trabalho de tratar o objeto.

 

vou dar um exemplo bem tosco do q eu to dizendo e sem abstração. Supondo uma requisição ajax:

 

$pdo = new pdo ('mysql: host=root; dbname=testes','root',NULL);
$p = $pdo->prepare('select * from catalogo');
$p->execute();
return json_encode($p->fetchAll(PDO::FETCH_OBJ));

 

este exemplo acima seria um padrão aceitavel para devolução dos dados?

 

Gabriel Heming, na verdade nunca utilizei frameworks. Estou utilizando php no desenvolvimento de projetos pessoais a 2 anos e assim continuarei até q eu me sinta 'confortável' para desenvolver aplicações comerciais como freelancer...

 

É por isso que sempre esponho minhas dúvidas para q eu não seja um mal profissional como muitos q se encontram no mercado hoje em dia...

já ouvi falar muito bem do zend e cake... por enquanto não pretendo utilizá-los ainda, mas assim q eu tiver um tempo pretendo ter uma experiência com os 2

[Gabriel Heming 766]

Eu torço um pouco o nariz na hora de usar frameworks, nada contra, é pessoal mesmo :pinch: . Mas devo admitir que o aprendizado gerado pela experiência que eu tive foi muito boa.

 

No final das coisas, não importa muuuuito a forma que você envia os dados para o front-end. O principal é, deixa o trabalho duro na model. Sempre seguindo os princípios do MVC: view burra, model gorda e controller magro e leve. Alguns acham que isso quer dizer não juntar PHP com HTML e vice e versa. O que de fato é errado, PHP foi feito para trabalhar com HTML e a mistura faz parte. O que você deve separar, e muito bem, é a responsabilidade de cada camada.

 

Mas não entendi o motivo pelo qual você quer usar javascript. Assim você dará mais responsabilidades ao cliente-side em processar o javascript. Pois, pelo seu exemplo, poderia ser muito bem feito pelo PHP.

[mangakah 217]

JSON é preferível ao XML pois este segundo tem quase o dobro do tamanho do primeiro para uma mesma quantidade de informações. E é o padrão de mercado para transmissão dentro de uma mesma aplicação. Mas Web Services ainda são feitos em XML, infelizmente.

 

O maior problema em delegar mais funções para o front-end é o receio de que isso possa comprometer a segurança da aplicação.

 

Pessoalmente, eu não sei porque o XML ainda não foi abandonado de vez, JSON e YAML o substitui com vantagens.

[Massaki 47]

Concordo com o Gabriel. É melhor processar tudo com o PHP. Se a velocidade de processamento não varia muito, o mais importante é o código estar inteligível e pronto para modificações a qualquer hora.

[Jhon Paulo 7]

hum.. entendi oq disseram.. oq eu tentei fazer passando responsabilidades para o cliente side seria poupar recursos do servidor...

 

supondo uma aplicação com muitas solicitações ajax, eu não ganharia em desempenho se utiliza-se o php apenas para buscar os dados no banco e utiliizar o js, já carregado, para fazer tratar e passar para o controler?

 

ao meu ver eu economizaria alguns loops no servidor e supondo sei lá uns 200 users online fazendo requisições ajax ao mesmo tempo, eu não estaria ajudando se passasse responsabilidades para js?

[Gabriel Heming 766]

Nesse caso, preocupe-se mais com a experiência do usuário do que o servidor.

 

Vou dar um exemplo. Existe um blog de humor que eu acessava, não mencionarei qual. Conteúdo a parte, toda vez que eu entro no blog, o meu pc trava, coisa de 5-10 segundos. Congela tudo mesmo, até o mouse. E de conteúdo, não tem nada de mais, uns videos, imagens, texto. Mas por algum motivo, o desenvolvedor resolveu tirar a prioridade do servidor e distribuir no cliente. Eu possuo um pc bom, nunca tive problemas de performance com ele, exceto com esse blog específico. Agora, do que adianta o conteúdo ser bom, o servidor rodar bem, se tenho frustrações todas as vezes que tento acessá-lo. E com um pc "comum", por assim dizer, pouca memória, pouco processamento. Vão acessá-lo?

 

Outra experiencia que eu tive foi com o Less. É um "otimizador" de css. Tanto na sintaxe como no tamanho do arquivo gerado. Ele possui dois compiladores, um cliente-side e outro server-side. O cliente-side possui a vantagem de carregar o arquivo menor e compilá-lo na abertura do site. Consome menos banda, mas consome mais recursos do cliente. E por fim, demora o mesmo tempo de carregamento. Já o compilador server-side, envia o arquivo já compilado para o cliente. O arquivo escrito no less é consideravelmente menor que um arquivo convencional de css com as mesmas propriedades. Já o arquivo compilado é, frequentemente, maior que o arquivo convencional. Logo, ocupa-se recurso do servidor e, ainda por cima, se envia um arquivo maior ao cliente. Resultado final, o único benefício do less era na escrita do css, por possuir uma sintaxe mais simples e consideravelmente menor. Para o usuário final, mais tempo de espera.

 

Assim como no SEO, que o principal foco são os usuários. Faça sistemas para os usuários, e pense na performance deles. Exceto que você esteja, especificamente, criando um sistema para um grupo de usuários com alto poder aquisitivo, o lado do cliente deve ser leve, sempre leve.

[Jhon Paulo 7]

agora sim entendi como deve ser feito; e vou dar o passo pro rumo certo :D

obrigado pelo esclarecimento..

espero que esse tópico seja útil para futuras visualizações..

[Bruno Augusto 417]

Eu fiz o model agora, daí fico na dúvida se vou mandar os dados via json, xml ou simples tags html

Tanto faz a forma como você vai retornar, entretanto XML e JSON são mais fáceis de se operar quando recebidos.

 

$pdo = new pdo ('mysql: host=root; dbname=testes','root',NULL);
$p = $pdo->prepare('select * from catalogo');
$p->execute();
return json_encode($p->fetchAll(PDO::FETCH_OBJ));

Você cometeu uns errinhos muito comuns nas etapas iniciais do MVC.

 

A model não abre uma conexão com o banco de dados, ela sim, usa um objeto de conexão.

 

A Model não deve saber que a PDO existe. Imagina que o cliente venha querer usar um SGBD que a PDO não suporte, mas existe biblioteca PHP para perá-lo. Seu sistema estará inflexível porque ele usa a PDO.

 

Se você ordenar que sua Model retorne os dados em JSON, você engessará teu sistema a SEMPRE retornar em JSON, quando, de repente, um XML caísse melhor.

 

Ou pior, se precisar retornar e XML tendo APENAS JSON, terá que realizar conversão de formatos, coisa que não precisaria se tivesse retornado apeas informações "cruas"

 

Vamos lá...

 

Eu uso o padrão Singleton Registry em cojunto com uma hinting de Interface para o construtor da minha Model.

 

De forma bem genérica e resumida, já que não tenho nenhum arquivo do meu sistema agora comigo, algo assim:

 

abstract class AbstractModel {

   protected $conn;

   public function __contruct( Driver $driver ) {

       $this -> conn = $driver -> getConnection();
   }

   public function query( $query, array $replacements = array() ) {

       $stmt = $this -> conn -> prepare( $query );

       $stmt -> execute( $replacements );

       return $stmt -> fetchAll();
   }
}

class Model extends AbstractModel {

   // ...
}

$model = new Model( Registry::getInstance() -> connection );

$data = $model -> query( 'SELECT * FROM tabela WHERE id = ?', intval( $_GET['id'] ) );

$data tem um array unidimensional com todos os dados do usuário em questão.

 

Agora, quanto ao retorno...

 

Principalmente em requisições AJAX é comum ver Controllers ecoando/printando as informações.

 

Você não é obrigado a criar uma View para as requisições AJAX, mas você também não deve cometer esse assassínio.

 

Todo tipo de output sequer é responsabilidade da View. Isso é outra coisa bastante comum de se ver, isto é, um método render() na classe View e este ecoando o conteúdo de um template incluído.

 

Isso porque muitos sistemas não têm um objeto Response próprio ou, quando têm, não lhe delegam tudo aquilo que é de sua alçada.

 

Novamente, outro exemplo resumido de como faço:

 

class Response {

   private $body;

   public function appendBody( $content ) {

       $this -> body .= $content;

       return $this;
   }

   public function addHeader( $header, $value = NULL ) {
      // ...
   }

   public function send() {

      // Envia Headers e Cookies

      $this -> sendHeaders();

      // Opcionalemente, limpa o conteúdo da Resposta

      echo $this -> body;
   }

   private function sendHeaders() {
       // ...
   }
}

class MeuController {

   /**
    * Método responsável pela requisição
    * http://www.domain.com/users/check
    *
    * Sem entrar em detalhes sobre como esse método
    * sabe que a requisição é para ele
    */
   public functio checkUsernameAction() {

       $model = new Model( Registry::getInstance() -> connection );

       $data = $model -> query( 'SELECT * FROM tabela WHERE id = ?', intval( $_GET['name'] ) );

       $response = new Response; 

       // Escolhendo a forma como os dados serão devolvidos

       $format = ( isset( $_GET['format'] ) ? trim( $_GET ) : 'json' );

       switch( $format ) {

           case 'xml':

               // Monta o XML

               $content = 'blah'; // Na verdade é o output da memória do XML montado

               $response -> addHeader( 'Content-type: application/xml' );

           break;

           case 'json':
           default:

               $content = json_encode( $data );

               $response -> addHeader( 'Content-type: application/json' );
           break;
       }

       $response -> send();
   }
}

Se a requisição for feita assim, pelo possível Framework JavaScript (ou na unha se você for o tal):

 

http://www.domain.com/users/check/name/Bruno Augusto/format/xml

Teremos um XML para manipular.

 

Se acessarmos o URL manualmente, pelo header enviado teremos um XML bonitinho de se ver.

 

Se for feita:

 

http://www.domain.com/users/check/name/Bruno Augusto

Teremos um JSON em tela. Aqui o header foi mais uma commodity, na verdade nem sei se um JSON é renderizado igual um XML pelo browser.

 

E por aí vai.

 

Lógico e evidente que todo esse código de formatos de output não deve ficar no Controller. Imagina se fosse, você teria de repetir tudo isso, toda vez. Na na ni na não. ^_^

 

Espero que seja uma luz pra ti.

 

Obs: Ignorem quaisquer violações das boas práticas de programação, escrevi tudo agora. ;)

[Jhon Paulo 7]

rrsrsr.. tu é igualzinho o João Neto.. valeeu a dica :D

como eu disse: vou dar um exemplo bem tosco do q eu to dizendo e sem abstração. Supondo uma requisição ajax

 

Em fim, não deu pra assimilar tudo q eu li do seu post na primeira vez(só li uma vez).. então vou postar como eu tava fazendo(com abstração) e vê se tem algum tipo de anomalia ignorando as responsabilidades do controler q ainda não desenvolvi.

 

<?PHP
// abstração da configuração da conexão
abstract class AbstractConnectionConfig {
	private $host;
	private $usuario;
	private $senha;
	private $banco;
	public function __construct ($host, $usuario, $senha, $banco) {
		$this->host=$host;
		$this->usuario=$usuario;
		$this->senha=$senha;
		$this->banco=$banco;
	}
	public function getHost () {
		return $this->host;
	}
	public function getUser () {
		return $this->usuario;
	}
	public function getPw () {
		return $this->senha;
	}
	public function getBanco () {
		return $this->banco;
	}
	abstract public function getDNS();
}

// configuração concreta da conexão q estou utilizando: MySQL
class MySQLConnectionConfig extends AbstractConnectionConfig{
	public function getDNS() {
		return sprintf ("mysql: host=%s; dbname=%s", $this->getHost(), $this->getBanco());
	}
}

// usado para as conexões MySQL... ainda não fiz a interface para conexões.
class MySQL {
	private $pdo;
	// conexão mysql
	public function conecta(MySQLConnectionConfig $c) {
		$this->pdo = new pdo ($c->getDNS(), $c->getUser(), $c->getPw());
	}
	// configuração conexao mysql
	public function configConexao($host, $usuario, $senha, $banco) {
		return new MySQLConnectionConfig($host, $usuario, $senha, $banco);
	}		
	// manipulação do banco de dados
	public function data ($str) {
		$a = $this->pdo->prepare($str);
		$a ->execute();
		return $a;
	}
	// percorrer consultas
	public function fetchAll($pdo) {
		$e = $pdo->fetchAll(PDO::FETCH_OBJ);
		return $e;
	}
}

// abstração para codificação dos dados: xml, json, YAML, etc.. (para oq eu to precisando, ta me servindo)
       // não sei se essa classe abstrata vai funfa(ainda não testei).. acho q tinha q ser interface...
abstract class AbstractDataConfig {
	abstract public function encode($str);
}

// devolução json
class JSON extends AbstractDataConfig {
	public function encode ($str) {
		return json_encode($str);
	}
}

       // aki seria responsabilidade do controler mandar fazer
$factory = new MySQL(); // crio nova conexão mysql
$factory->conecta($factory->configConexao('localhost','root',NULL,'euscritor')); // configuro a conexão
$factory_data = new JSON; // os dados serão enviados via json;
return $factory_data->encode($factory->fetchAll($factory->data('select * from catalogo'))); // aki uma pequena anomalia em factory->data()

?>

[Bruno Augusto 417]

Olhando assim por cima...

 

abstract class AbstractConnectionConfig {

   private $host;
   private $usuario;
   private $senha;
   private $banco;

   public function __construct ($host, $usuario, $senha, $banco) {

       $this->host=$host;
       $this->usuario=$usuario;
       $this->senha=$senha;
       $this->banco=$banco;
   }

   // ...

   abstract public function getDNS();
}

O que você fez aqui estaria certo se não estivesse usando duas abordagens diferentes ao mesmo tempo.

 

Nesses moldes, tudo indica que um Singleton Registry ou uma... eac, variável global seria utilizada. Nesse sentido, exigir a quem utilizar host, user, password e database é até... aceitável.

 

Aceitável porque subentende-se que você vá usar todas as informações e conectar manualmente no banco, como nos tempos do velho mysql_connect().

 

Mas como você também está exigindo para as classes concretas um DSN, o que caracteriza certo dinamismo, você estaria apenas desperdiçando informações, uma vez que nem todos os drivers suportados pela PDO utilizam todas essas quatro informações.

 

Sem contar o fato que eu acabo economizando nos accessors, de quatro (um para cada informação) para apenas um, opcional diga-se de passagem, que retorna todas as opções que estão sendo informadas para o objeto.

 

Eu faço algo assim (confiar na memória é dureza :P)

 

abstract class AbstractPDO {

   protected $conn;

   public function connect( $options ) {

       $this -> pdo = new \PDO(

           $this -> getDSN( $this -> options() ),

           $options -> user, $options -> password
       );
   }

   abstract protected function getDSN();
}

class MySQL extends AbstractPDO {

   protected function getDSN( $options ) {

       // Verifica se $options -> database e $options -> host existem

       return sprintf(

           'mysql:dbname=%s;host=%s',

           $options -> database, $options -> host
       );
   }
}

class SQLite extends AbstractPDO {

   protected function getDSN( $options ) {

       // Verifica se $options -> database existe

       return sprintf( 'sqlite:%s', $options -> database );
   }
}

Eu tenha uma verificação adicional para que as informações de user e password só sejam utilizadas se informadas, mas não vem ao caso (desculpa de quem não lembra :lol:).

 

Num projeto de testes que tenho, uso os dois bancos ao mesmo tempo, cada qual em um índice do Registry e cada um deles é configurado de uma forma diferente, já que para o SQLite só preciso do path de localização do arquivo.

 

abstract class AbstractDataConfig {
   abstract public function encode($str);
}

Essa aqui vou apenas citar por causa do comentário imediatamente acima dela.

 

Eu particularmente adoto o seguinte:

 

- Se um método só pode ser acessado internamente em contexto de herança e existe essa exigência de diferentes implementações por parte da classe abstrata, o método só pode ser protected e, logo, também abstract

 

- Se um método pode ser invocado a nível de instância, logo ele deve ser public e um método público tem sua assinatura (e não sua implementação) conhecida pelo usuário, sendo assim, fecha contrato com uma interface, que só aceita métodos públicos.

 

Ou seja, nunca tenho métodos abstract public ^_^

 

E, obviamente, me abstract private o.O (nem sei se isso é possível de se declarar, de tão absurdo que é)

 

rrsrsr.. tu é igualzinho o João Neto.. valeeu a dica :D

Não, eu sou bunitu :lol:

[Jhon Paulo 7]

ou velho se der pra você postar o seu código completo com as verificações dps eu agradeço, dei uma olhada e é bem intereçante a sua sacada. Não vou copiar, apenas dar uma espiadinha B)

 

- Se um método só pode ser acessado internamente em contexto de herança e existe essa exigência de diferentes implementações por parte da classe abstrata, o método só pode ser protected e, logo, também abstract

com certeza, minha intensão era essa sahuhsau..

abstract protected não vou esquecer..

 

- Se um método pode ser invocado a nível de instância, logo ele deve ser public e um método público tem sua assinatura (e não sua implementação) conhecida pelo usuário, sendo assim, fecha contrato com uma interface, que só aceita métodos públicos.

exatamente! Abstract public é uma interface.

 

eu vou trocar para abstract protected e não para interface, já q no futuro eu poderia fazer alguma implementação na classe.

 

Não, eu sou bunitu :lol:

ri acho q 1 minuto sem parar shauhsuhsauha...

[Bruno Augusto 417]

Vou ficar devendo os códigos.

 

Não apenas por fazer parte de uma coisa maior, mas porque o módulo DB deu um trabalho do cão (reescrevi sete vezes :o) pra fazer e, apesar de testado (mesmo que manualmente) ainda não estou seguro de sua implementação, apesar de eu ter achado fuderosa. ^_^

[Jhon Paulo 7]

shaushuahsa, jaé.

[Henrique Barcelos 290]

Faz tempo que estou querendo comentar aqui... Hoje finalmente arranjei tempo, mas meu pc resolveu pifar quando eu já tinha escrito metade da resposta --'.

Enfim...

 

No final das coisas, não importa muuuuito a forma que você envia os dados para o front-end. O principal é, deixa o trabalho duro na model. Sempre seguindo os princípios do MVC: view burra, model gorda e controller magro e leve.

Vou ter que discordar um pouco aqui...

 

Importa sim como você envia os dados. Você tem que ter um padrão. Não adianta a resposta ter uma estrutura para o método getAll de uma classe e uma diferente em outra, imaginando que haja uma hierarquia entre ambas, ou uma interface comum.

 

Como o PHP é muito livre, você pode fazer esse tipo de coisa. Tendo um pouco de contato com Java e C, percebi que é bastante útil restringir o tipo de retorno de um método ou função.

O problema é você, ou outra pessoa, dar manutenção nesse código. Nas versões mais antigas dos meus códigos eu fico completamente perdido, parece até que foi outra pessoa que fez. Quando você padroniza seu desenvolvimento, alterações se tornam muito menos penosas.

 

Essa história de "view burra, controller magro e model gordo" é apenas uma sugestão de implementação do MVC. Existem algumas outras.

 

Já ouviu falar de Active Model x Passive Model?

:seta: http://msdn.microsof...y/ff649643.aspx

 

Para sistemas web, é um tanto complicado implementar um Active Model pois eles são baseados em requisições, que tem iniciam e terminam enquanto a aplicação ainda está rodando (você pode operar sobre uma página gerada, mesmo quando a requisição ao servidor já terminou). Uma possibilidade para sistemas em tempo real, como fazem o Facebook e o Twitter é o uso de uma técnica chamada Server Push que vai manter a conexão aberta enquanto a página estiver no navegador. Isso é feito assincronamente através de uma requisição Ajax.

 

O mais comum que se encontra em sistemas baseados na arquitetura MVC sobre o caminho dos dados para efetuar uma requisição é:

View ---> Controller ---> Model ---> Controller ---> View

 

Eu utilizava esse método, estou tendendo a mudar. Isso gera um certo acoplamento entre o Controller e o Model. Se alterar o Model, talvez tenha que alterar o Controller e a View.

Estou tentando encontrar uma maneira de fazer desta maneira:

View ---> Controller ---> Model ---> View

Ou seja, fazer com que o Model se comunique diretamente com a View, algo como um Active Model adaptado. Como estou meio sem tempo, não pude pensar muito bem nisso ainda.

Preciso primeiramente definir um protocolo de comunicação entre as classes e seguir sempre o mesmo padrão.

 

Eu acho que vou seguir na linha do que o Bruno Augusto sugeriu.

Você pode pensar em cada busca de dados antes de gerar o HTML, XML, JSON, etc. como uma "requisição interna", feita para o controller.

Tal como uma requisição HTTP, essa requisição obrigatoriamente tem uma resposta. O conteúdo (corpo) da resposta pode ser de qualquer tipo que você definir (por exemplo, HTML, XML e JSON).

Suas Views podem retornar dados nesses formatos definidos, mas não exibi-los.

 

Mas como assim??? Se eu quiser criar um template PHP, como vou criar as tags sem exibir a resposta. Você quer que eu defina tudo em strings PHP para só depois mostrar a saída através da resposta???

Acredite, não quero que você faça isso.

Existe uma maneira de colocar tags HTML num template sem fornecer a saída para o navegador imediatamente. Essa solução chama-se OutputBuffer, algo que conheço não faz tanto tempo quanto deveria.

:seta: http://br.php.net/ob_start

 

Qual a ideia então?

Bom, na sua View você definirá a estrutura do corpo da resposta, seja HTML, XML, JSON, ou o "carvalho de 4".

Com o advento do output buffer, no objeto Response (resposta da "requisição"), você pega seu conteúdo e finalmente joga a saída para o navegador.

A vantagem de usar o buffer é que você pode compactar a saída com gzip, por exemplo, reduzindo bastante o tamanho dos dados de transferência.

Eu só testei com HTML até hoje, mas deve funcionar com outros formatos também.

 

Com essa abordagem, você pode ter várias Views diferentes para uma mesma requisição. Imagine que se você tiver uma requisição normal, você quer fornecer a saída em HTML já formatado. Se for uma requisição AJAX, você quer uma saída JSON. Ao invés de ficar fazendo condicionais na View, crie duas separadas mesmo, vai facilitar bastante, apesar de não parecer.

[Gabriel Heming 766]

Só explanando o mau entendido Henrique. Padrão é importante sim, não falei que não. Mas como eu me referi ao método de envio, não era sobre não padronizar, era sobre utilizar PHP ou Javascript. Só PHP ou só javascript. Mas se for enviar em um lugar um Json e outro um XML e depois uma string separada por PIPE, já não cabe mais a explicações...

As vezes não tenho tempo de dar uma resposta mais completa, e a percepção do que eu tentei responder pode ser diferente em outra linha de tempo (com respostas mais recentes). No contexto inicial, ele queria processar tudo por javascript, não havia pensado em utilizar o PHP. Acho que assim fica mais entendível.

 

Edit----

 

Só corrigindo. Do Twitter não sei dizer, mas o Facebook utiliza LongPoling. Que é parecido, mas não o mesmo. Digo isso pois, utilizando uma ferramenta que monitora requisições (Firebug possui essa opção desativa por padrão), pude avaliar o funcionamento do facebook. Realizando vários teste, foi definido que ele utiliza Long Polling, e não Server Push.

[Jhon Paulo 7]

adimito que até você dizer:

A vantagem de usar o buffer é que você pode compactar a saída com gzip

eu não estaava nem prestando atenção kk'

 

ah também achei muito intereçante a abordagem sobre Server Push... é híper recomendável para requisições ajax.

 

Agora imagina server push com buffer? "Tempo real?" rsrs

valeu a dica ;)

 

ta faltando só eu aprender um pouco do inglês mesmo pra eu poder estudar essas paradas, pq em português agnt só encontra de maneira artificial...

 

alguém sabe como um servidor pode dizer ao cliente: Receba isso!

Sem o cliente pedir?

[Henrique Barcelos 290]

Na verdade, Long Polling é um tipo de Server Push :thumbsup:

 

alguém sabe como um servidor pode dizer ao cliente: Receba isso!

Sem o cliente pedir?

Sem o cliente pedir não tem como...

 

A ideia é bem simples, na verdade é meio ridícula, consiste de um loop infinito:

<!doctype HTML>
<html>
<head>
	<title>Long Pooling Test</title>
	<script type="text/javascript" src="http://code.jquery.com/jquery-1.7.2.min.js"></script>
	<script type="text/javascript">
		var timestamp = null;

		function waitForMessage() {
			$.ajax({
				type: 'POST',
				data: {'timestamp' : timestamp},
				url: 'lp.php',
				cache: false,
				dataType: 'json',
				success: function(json) {
					if(json.message != '') {
						document.getElementById('container').innerHTML = json.message + '<br/>';
					}
					timestamp = json.timestamp;
					setTimeout(waitForMessage, 3000);
				}					
			});
		}			
		$(document).ready(waitForMessage);
	</script>
</head>
<body>
	<button type="button">Hi!</button>
	<div id="container"></div>
</body>
</html>

 

<?php
$filename = "data.txt";

$lastModif = isset($_POST['timestamp']) ? $_POST['timestamp'] : 0;
$currModif = filemtime($filename);

while($currModif <= $lastModif) {
usleep(100000); // dorme 100ms para poupar o servidor; pode ser mais ou menos, dependendo da aplicação
clearstatcache(); // limpa o cache
$currModif = filemtime($filename);
}

$response = array();
$response['message'] = file_get_contents($filename);
$response['timestamp'] = $currModif;

echo json_encode($response);

 

Esse código fica obtendo a data de alteração do arquivo até que ele seja alterado (a data de alteração seja maior que a anterior).

Quando isso ocorrer, ele faz o push. Essa é a famosa técnica do long polling. Quando eu descobri o que era fiquei muito put0...