A OFIBO entra em tempo real: as notificações push do Firebase já estão ativas

17 de setembro de 2026

O dia 17 de setembro foi um daqueles dias de desenvolvimento em que uma funcionalidade que parece simples no ecrã exigiu uma enorme quantidade de trabalho nos bastidores.

Hoje construímos a base para notificações push reais na aplicação móvel da OFIBO, ligando a aplicação Android, o backend Laravel, o Firebase Cloud Messaging, as filas em segundo plano e o nosso servidor de produção.

O resultado é importante: a OFIBO pode agora notificar automaticamente os utilizadores nos seus telemóveis quando acontece atividade relevante na plataforma.

O Firebase já está ligado à OFIBO

A parte mais importante do trabalho de hoje foi integrar o Firebase Cloud Messaging na OFIBO.

Configurámos o projeto Firebase ofibo-app e alinhámos a aplicação Android com o pacote de produção da OFIBO:

com.ofibo

A configuração Firebase para Android, a configuração Expo e o projeto Android nativo apontam agora para a mesma identidade de aplicação de produção.

Isto pode parecer uma pequena alteração de configuração, mas afeta várias camadas de uma aplicação Android com React Native / Expo. Os identificadores de pacote, a configuração nativa do Gradle, os pacotes Kotlin, a configuração Firebase e as credenciais EAS têm de coincidir entre si.

Movemos a OFIBO para a identidade Android de produção correta

Outro trabalho importante de hoje foi padronizar a aplicação móvel em torno de com.ofibo.

Atualizámos a configuração Expo, o namespace Android, o application ID e a estrutura dos pacotes Kotlin nativos para que o projeto utilize uma única identidade de produção coerente.

Também resolvemos artefactos desatualizados de compilação e geração de código Android que tinham ficado da antiga estrutura de pacotes.

Depois de limpar essas referências nativas de compilação, a geração de código do React Native voltou a funcionar corretamente.

Tokens push nativos no Android

A OFIBO não se limita a enviar uma notificação genérica a partir do frontend. Cada dispositivo móvel com sessão iniciada tem agora o seu próprio token do Firebase Cloud Messaging.

Criámos suporte no backend para registar esses dispositivos na OFIBO.

A aplicação móvel pode agora registar o seu token FCM nativo depois da autenticação e atualizá-lo quando o Firebase faz a rotação desse token.

Quando um utilizador termina sessão, o dispositivo também pode ser desativado para que a OFIBO não continue a enviar notificações autenticadas da conta para um dispositivo que já não as deve receber.

Um novo sistema de dispositivos no backend Laravel

No backend introduzimos um registo de dispositivos dedicado às notificações push.

A OFIBO guarda agora os dispositivos dos utilizadores e se cada dispositivo está atualmente ativo.

Adicionámos endpoints autenticados da API para registar e desativar dispositivos:

POST /api/push-devices
DELETE /api/push-devices

O registo de tokens também foi tornado seguro contra condições de corrida através de um upsert atómico na base de dados. Isto é importante porque as aplicações móveis podem iniciar o registo de dispositivos mais do que uma vez durante a autenticação, renovação de tokens ou arranque da aplicação.

Firebase HTTP v1 a partir do Laravel

A API Laravel da OFIBO pode agora comunicar diretamente com o Firebase através da moderna API HTTP v1 do Firebase Cloud Messaging.

Em vez de guardar credenciais sensíveis do Firebase dentro do repositório da aplicação ou do diretório web público, a credencial da conta de serviço Firebase de produção é guardada separadamente no servidor.

O Laravel utiliza essas credenciais para se autenticar de forma segura com o Firebase e enviar notificações para dispositivos Android registados.

Os seguidores podem receber avisos sobre nova música

O sistema de notificações já está ligado a uma das relações mais importantes dentro de uma plataforma musical: seguir artistas.

Quando um artista publica uma nova canção pública, a OFIBO consegue identificar os seguidores desse artista, encontrar os seus dispositivos móveis ativos e preparar notificações para eles.

Ligámos isto tanto ao fluxo de upload do Artist Studio como ao fluxo administrativo de upload de canções, por isso o comportamento não depende da interface da OFIBO utilizada para publicar a faixa.

A lógica baseia-se na publicação de uma nova canção pública e não numa categoria musical específica, mantendo a funcionalidade flexível à medida que a OFIBO cresce.

Novos posts publicados também podem gerar notificações

A mesma infraestrutura foi expandida para além da música.

Novos posts publicados na OFIBO também podem ser enviados através do sistema de notificações push, dando-nos uma base comum de notificações que, no futuro, poderá suportar muitos tipos diferentes de atividade da plataforma.

As notificações são processadas através das filas do Laravel

Uma decisão arquitetónica importante foi manter o trabalho do Firebase fora do pedido de upload do utilizador.

Publicar uma canção não deve ficar lento apenas porque centenas ou milhares de seguidores podem precisar de receber notificações.

Em vez disso, a OFIBO cria um job numa fila em segundo plano.

O upload termina normalmente e o trabalho de notificação é processado separadamente.

Isto também significa que um problema temporário com o Firebase não impede um artista de publicar corretamente uma canção.

Colocámos o worker da fila em produção

Criar jobs de fila localmente é apenas metade do trabalho. É preciso algo que continue a processá-los continuamente em produção.

Hoje configurámos o Supervisor para executar permanentemente o worker da fila de base de dados do Laravel da OFIBO no servidor de produção.

Isto significa que as notificações já não dependem de alguém executar manualmente:

php artisan queue:work

O worker permanece ativo e processa automaticamente os novos jobs de notificação à medida que entram na fila.

Encontrámos um problema real de permissões em produção

Durante os testes em produção encontrámos um dos problemas mais interessantes do dia.

O Firebase parecia estar configurado corretamente quando os comandos eram executados como utilizador root do servidor, mas o worker permanente do Supervisor continuava a indicar que o Firebase não estava configurado.

A causa acabou por não ser o próprio Firebase.

O diretório de credenciais do Firebase tinha permissões do sistema de ficheiros que permitiam ao root aceder-lhe, mas impediam o utilizador www, que executava o worker da fila, de atravessar e ler o caminho das credenciais.

Depois de aplicarmos as permissões corretas de grupo e acesso ao diretório, o worker Laravel de longa duração conseguiu autenticar-se corretamente com o Firebase.

Foi uma correção importante em produção porque demonstrou que o sistema de notificações funcionava sob o utilizador e processo reais do servidor responsáveis por entregar as notificações todos os dias.

Depois testámos toda a cadeia

Quando todas estas peças ficaram ligadas, realizámos o teste que realmente importa.

Publicámos uma canção pública real.

A cadeia completa ficou assim:

Nova canção → Laravel → job de fila → Supervisor → Firebase → dispositivo Android → notificação

E funcionou.

Mais importante ainda, a notificação seguinte funcionou automaticamente através do Supervisor sem iniciar manualmente um worker de fila.

Isto confirmou que não se tratava apenas de um teste de desenvolvimento bem-sucedido. A própria pipeline de notificações de produção estava a funcionar.

Preparar a OFIBO para builds Android de produção

Também continuámos a preparar a aplicação Android para o seu canal adequado de builds de produção através do Expo Application Services.

O projeto EAS da OFIBO está ligado à aplicação de produção e utiliza agora com.ofibo como pacote Android.

Verificámos a configuração Firebase com esse pacote e confirmámos as credenciais de assinatura Android guardadas pelo EAS.

O perfil de build de produção está configurado para criar um Android App Bundle e utilizar incremento automático remoto de versão, a direção necessária para futuras versões de produção.

O Expo Doctor também terminou corretamente com as 21 verificações aprovadas, dando-nos uma base muito mais limpa para o próximo build móvel de produção.

Muito mais do que uma janela de notificação

Do ponto de vista do utilizador, o trabalho de hoje aparece como algo muito simples: chega uma notificação ao telemóvel.

Por trás dessa notificação existe agora toda uma infraestrutura OFIBO:

• Firebase Cloud Messaging
• Autenticação Firebase HTTP v1
• Tokens FCM nativos do Android
• Registo de dispositivos de utilizador
• Gestão da renovação de tokens
• Desativação de dispositivos ao terminar sessão
• Descoberta de seguidores
• Eventos de publicação de canções
• Notificações de publicação de posts
• Jobs de fila do Laravel
• Um worker permanente do Supervisor
• Gestão de credenciais de produção
• Migração do pacote Android para com.ofibo
• Configuração de produção do Expo e EAS

Um enorme passo para a OFIBO Mobile

O dia 17 de setembro não foi apenas adicionar um botão ou alterar uma página.

Ligámos vários sistemas independentes e fizemos com que trabalhassem em conjunto como uma única pipeline de produção.

A OFIBO tem agora a base técnica para comunicação em tempo real entre a plataforma e os seus utilizadores móveis.

Hoje pode avisar os seguidores de que um artista lançou uma nova canção. Com o tempo, a mesma infraestrutura poderá alimentar muitos outros eventos importantes da OFIBO sem reconstruir o sistema de notificações de raiz.

Foi uma enorme quantidade de trabalho invisível, mas aproximou significativamente a OFIBO de se comportar como uma plataforma musical nativa completa, em vez de ser apenas um site dentro de uma aplicação móvel.

17 de setembro de 2026: Firebase, Android e o backend da OFIBO começaram finalmente a comunicar entre si em produção.