As notificações ao vivo são onde os Websockets prosperam e oferecem uma enorme vantagem sobre o AJAX.

Como você sabe, isso já foi discutido antes quando debatemos o papel do AJAX (ótimo para CRUD, não tanto ao fazer pesquisas) e ao comparar Desempenho de websocket vs. desempenho de AJAX (Websockets são sempre mais rápidos quando se trata de atualizações ao vivo).

Sim... você pode economizar recursos e melhorar o desempenho (bem como futuros problemas de manutenção de código) adicionando on_update "ganchos" ao ponto de acesso do banco de dados.

A ideia é simples:sempre que uma chamada de função atualiza o banco de dados MySQL, a solicitação de atualização também é enviada para um callback. Esse retorno de chamada é responsável por publicar a atualização no canal correto.

Dessa forma, você não pesquisa o banco de dados MySQL.

Alguns bancos de dados oferecem retornos de chamada de atualização e outros não. Eu acho que o MySQL faz. No entanto, evito esses retornos de chamada vinculados ao banco de dados porque eles são específicos do banco de dados. É melhor (IMHO) adicionar o retorno de chamada ao ponto de acesso do banco de dados no aplicativo, portanto, a substituição de um banco de dados não afeta a base de código.

Eu não acho que AJAX é uma boa abordagem.

O HTTP/2 ajuda a mitigar as deficiências do AJAX, mas não resolve todas elas.

Não sei quantos clientes você espera que estejam conectados simultaneamente, mas forçar um cliente a enviar uma solicitação a cada segundo ou dois é muito próximo de um ataque DoS auto-infligido.

Considere o seguinte:se um cliente enviar uma solicitação AJAX a cada dois segundos, do que em 2.000 clientes simultâneos, seu servidor precisará responder a 1.000 solicitações/seg - isso inclui autenticação, consultas de banco de dados e tudo mais.

Por outro lado, usando Websockets, com 2.000 clientes conectados, você tem 2.000 conexões persistentes sem fazer nada até que uma mensagem chegue. Não requer CPU ou trabalho, apenas a memória da conexão. Não há estresse no servidor até que os dados reais sejam enviados.

Sim, eles são mais complexos de implementar, mas não são tão difíceis assim que você começa. Além disso, há muitas bibliotecas e ferramentas auxiliares que tiram muito do trabalho de seus ombros.

Problemas comuns relacionados à abordagem Websocket incluem o manuseio do dimensionamento horizontal (geralmente adicionando um banco de dados ou serviço pub/sub, como Redis), ordenação de mensagens (que é melhor ignorada quando possível) e preocupações de propagação de dados (quando marcamos dados como "vistos"? enviamos todos os dados ou apenas uma notificação informando que os dados estão disponíveis? quantos canais usamos e como dividimos as assinaturas?).

Normalmente, as respostas são específicas do aplicativo e dependem do recurso que você está tentando desenrolar, bem como do tamanho esperado do seu conjunto de dados (se cada resposta que eu dei no SO fosse um canal, seria irreal mantê-lo).

De qualquer forma, boa sorte!