Skip to content

Instantly share code, notes, and snippets.

@olavocneto
Last active August 29, 2015 14:11
Show Gist options
  • Save olavocneto/5e4421551a9c89af8ad9 to your computer and use it in GitHub Desktop.
Save olavocneto/5e4421551a9c89af8ad9 to your computer and use it in GitHub Desktop.

Objetivo?

Atualizar dashboard. Quando houver modificação em duas tabelas, foo e bar, então fazer front end requisitar novamente api.

Possível solução: index.html: Abro um socket.

  var conn = new WebSocket('ws://localhost:8080/push-dashboard');
  conn.onopen = function(e) {
      console.log("Connection established!");
  };

  conn.onmessage = function(e) {
      console.log(e.data);
  };

Crio três TRIGGER em cada tabela; foo e bar. AFTER INSERT ON, AFTER UPDATE ON ou AFTER DELETE ON para cada linha chamo PROCEDURE: sys_exec('curl http://example.com/push-update');

Crio uma rota para '/push-update' quem tem como objetivo "pegar o component, objeto que implementa Ratchet\MessageComponentInterface" e enviar uma mensagem para todos os clientes conectados.

O front end quando receber a mensagem irá reliazar as requições para atualizar os dados.

Dúvidas?

Qual sua opinião sobre a lógica? Como enviar do server para o client uma mensagem?

@ramcoelho
Copy link

Não sou muito fã de chamadas externas em triggers. A atualização do banco será infinitas vezes mais rápida que o retorno daquela chamada curl e isso pode trazer problemas no enfileiramento. A minha primeira opção para abordar um caso desses seria encapsular as operações que resultem em mudança de tuplas destas tabelas em uma classe (ou algumas) de maneira a centralizar todas as chamadas e evitar o uso de triggers. Em seguida, usariam alguma ferramenta como o Gearman para realizar a notificação dos clientes em segundo plano, liberando a operação de atualização o quanto antes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment