-
Notifications
You must be signed in to change notification settings - Fork 370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Criar o sistema de notificação via API e interface web (em complemento ao email) #738
Comments
Nunca implementei um sistema de notificações, então dei uma pesquisada e tentei elaborar quais são as nossas necessidades para conseguir progredir com o issue, principalmente porque isso é uma dependência para outras melhorias. Eu precisaria fazer esse estudo de qualquer forma para eu mesmo, então resolvi compartilhar aqui, até porque alguém pode saber mais do assunto e contribuir. Separei as características entre o que é necessário e o que é desejável, assim fica fácil decidir o que deixar de lado durante a implementação dependendo do custo e complexidade. Das referências que li sobre o assunto, vale compartilhar o artigo Designing a notification system - Tan Nguyen e também essa thread do Reddit que contém possíveis soluções para alguns problemas que menciono no próximo tópico. Podem até ler antes de continuar o meu comentário, se preferirem. Necessário
DesejávelJá falei sobre alguns desses pontos no tópico anterior, mas vou listar novamente para ficar fácil de encontrar.
Solução própria ou de terceiros?CustosTemos uma ideia dos custos na época do lançamento do TabNews, mas sem nada específico para estimarmos com base em armazenamento ou demora das consultas:
Nas minhas pesquisas, encontrei várias soluções de terceiros sugeridas para esse tipo de problema, então precisei ler como elas resolvem isso e qual o custo envolvido.
Dos quatro serviços mencionados acima, três (Novu, Knock e MagicBell) fornecem soluções de UI e se vendem como otimizadores de tempo para implantar o sistema de notificação. O esquema de precificação do MagicBell me faria excluí-lo da lista (por usuário ativo/mês), e o preço do "próximo custo" do Knock é muito alto. Sobra o Novu, mas vou mencionar novamente o Ably mais para frente. Implementação própriaAlém da estrutura do banco de dados, similar ao que foi mencionado nos links de referência (Medium e Reddit), no backend teríamos a responsabilidade de:
No frontend, precisaríamos implementar a interface. O GitHub possui uma página de notificações, mas não uma "caixa simples" de notificações (como o Stack Overflow, Reddit e Facebook). Para fazermos isso, provavelmente precisaríamos usar o Fiquei em dúvida se poderíamos usar server-sent events para notificar o cliente em tempo real. Nunca usei SSE e os exemplos que vi não me deram a certeza, principalmente considerando o ambiente serverless. Aqui a Vercel não menciona o SSE como alternativa ao WebSocket, mas indica o Ably. ViabilidadeCriar algumas tabelas no banco de dados e ter o controle próprio me parece muito bom: não teremos uma dependência extra e nem um custo financeiro por essa nova dependência. Para saber se conseguiríamos lidar com isso criando as tabelas (como mencionado nos links de referência e adaptando para nossas necessidades) com bom desempenho, podemos fazer alguns testes na casa de milhões de notificações localmente. Seria interessante fazer o teste também em ambiente de homologação e entender os custos. Pegando um mês inteiro pela página /status, e sem o efeito dos feriados de fim de ano, escolhi de 15/11 até 15/12. Nesse período, tivemos:
Se considerarmos uma notificação por comentário (como acontece com e-mails hoje) e uma por voto recebido, teríamos 7.469 notificações. Isso ainda deixaria uma certa margem para os 10 mil eventos gratuitos do Novu, onde a próxima faixa é 20 mil eventos por US$ 25. Temos 3 opções:
Imagino que, para a opção que envolve migração, precisaríamos armazenar as notificações desde o início no banco de dados para conseguirmos exibir para os usuários as notificações antigas (que é desejável, mas não obrigatório, e talvez nem precise armazenar todas notificações, só alguns tipos). Mesmo assim, nós poderíamos aproveitar o componente de UI do Novu e a parte de notificar o cliente. E numa "versão beta" poderia descartar a parte de nós salvarmos as notificações, tendo o Novu. O que vocês acham?Qual opção parece fazer mais sentido para vocês? Já precisaram implementar um sistema parecido e tem alguma informação para acrescentar aqui? |
Não vejo razão para armazenar as notificações por tempo indeterminado. Acho que as visualizadas podem ser excluídas após um certo tempo e/ou quantidade.
Também acho que devem ser excluídas se o que elas estiverem notificando deixar de fazer sentido. |
Hoje temos o email para notificações, mas não seria interessante ter um endpoint na api pra isso também? Algo como
GET api/v1/notifications
E isso retornaria as notificações que o usuário tem.
Porque?
A maior utilidade ao meu ver seria criar um menu de notificações no frontend, parecido com o do youtube:
youtube.dropdown.mp4
Também poderia ser usado pra push notifications, etc..
The text was updated successfully, but these errors were encountered: