Oi André,

olha, vou te falar a estratégia que estou adotando no caso do Twitter, que é o meu alvo para o próximo release do Grails Brasil.

Não estou implementando nada similar ao que você está querendo, mas sei mais ou menos qual o caminho das pedras. Como mencionei, vou descrever o que está relacionado ao Twitter, mas acredito que seja muito (na realidade, É) próximo do que você faria com o Facebook.

Se quero ver quem está postando coisas sobre o Grails Brasil, posso fazer uma busca por hash tags usando a própria API Rest do serviço. Cada registro que encontro, possui um identificador. Caso queira fazer algo com este post, e não queira processá-lo duas vezes, salvo o seu código (e talvez conteúdo) em algum lugar (banco de dados, txt, whatever) e, em seguida, nas próximas buscas, ignoro o que estiver salvo nesta lista.

No caso do Facebook (meu próximo alvo), vi que há inclusive uma chamada de API justamente para o "Curti". Aplicaria portanto a mesma estratégia nesta situação.

Oi Henrique, o problema não é COMO obter as informações, mas sim a frequência da busca. A melhor solução envolveria uma aplicação no lado do servidor também. A estratégia mais simples seria estabelecer a frequência via jQuery por exemplo, o efeito negativo dessa solução é ficar consultando desnecessariamente, pois nem sempre vamos ter algo a notificar. Caso o número de usuários aumente demais, também não funcionaria bem. A solução "push" é funciona bem para sites pequenos. Valeu!

Oi André,

neste caso, você pode ter um acumulador de respostas do lado servidor que faça as buscas periódicamente, usando algum motor de agendamento, como por exemplo o Quartz. Enquanto isto, na parte web, você talvez nem precise usar o jQuery, use a função setInterval para que sejam feitas consultas periódicas ao servidor.

Neste acumulador, você inclui as requisições de todos os clientes, e o usa como um singleton, enquanto na outra ponta, os clientes simplesmente executam consultas a este acumulador usando um token como chave.