A parte de agendamento de um agendador de redes sociais é coisa de um fim de semana. Uma fila, um worker, um cron. Isso genuinamente não é difícil, e é por isso que a estimativa está sempre errada.
Tudo o que é caro está do outro lado disso.
A parte que é fácil
Uma tabela de publicações com um horário agendado, um worker que acorda, encontra as publicações pendentes e as publica. Adicione uma nova tentativa e está pronto.
Se você está construindo isso como um projeto de aprendizado ou para uma única plataforma que você controla, pare de ler aqui. O resto disto é sobre o que acontece quando contas reais e múltiplas plataformas estão envolvidas.
O modelo de dados que você realmente precisa
Mais estados do que as pessoas esperam:
- rascunho, criado mas não enfileirado
- agendado, enfileirado para um horário
- em processamento, enviado à plataforma, resultado desconhecido
- publicado, confirmado
- falhou, com um motivo
- parcial, publicado para alguns destinos e não para outros
em processamento existe porque várias plataformas aceitam uma publicação e a publicam de forma assíncrona. Um 200 não é uma publicação, e o resultado chega depois, fora de banda. Sem esse estado, sua interface afirma sucesso e às vezes está errada.
parcial existe porque uma publicação normalmente tem como alvo várias plataformas. Três têm sucesso, uma falha. Nem “publicado” nem “falhou” é verdadeiro, e forçar em um dos dois produz um produto que mente para seus usuários.
Você também precisa de linhas por destino em vez de um único status na publicação, porque a falha é por plataforma.
Fusos horários
Armazene o instante e o fuso IANA, não um deslocamento.
“Toda segunda a sexta às 9h no horário local” é um instante UTC diferente antes e depois de uma mudança de horário de verão. Armazenar apenas UTC funciona até março, depois tudo desvia em uma hora e os relatos de bugs ficam confusos porque está correto metade do ano.
O trabalho com as plataformas
É aqui que a estimativa quebra. Por plataforma:
Um fluxo OAuth separado. Escopos diferentes, tempos de vida de token diferentes, telas de consentimento diferentes.
Um job de atualização separado. Esse é o que dói. Os tokens expiram, a atualização falha silenciosamente, e ninguém descobre até que uma publicação agendada não saia. Você precisa de atualização agendada, monitoramento de falha de atualização, um estado de conexão quebrada e um fluxo de reconexão. Isso é mais trabalho do que o próprio fluxo OAuth.
Um pipeline de mídia separado. Uma plataforma busca uma URL, outra quer upload em blocos retomável, outra quer dimensões ou codecs específicos. Você vai precisar hospedar e possivelmente transcodificar.
Um limite de taxa separado, com sua própria janela e seu próprio comportamento quando excedido.
Revisão do aplicativo. Várias plataformas condicionam a publicação a uma revisão que envolve seu aplicativo, uma política de privacidade e, às vezes, um vídeo de demonstração. Isso é tempo de calendário que você não controla, e pode ser recusado.
Mudança perpétua. Versões de API ficam obsoletas, campos são renomeados, permissões são restringidas, no cronograma das plataformas. Cada uma dessas é trabalho não planejado com um prazo que você não definiu.
Multiplique pelo número de plataformas. Depois continue pagando por isso, para sempre.
As regras de publicação
Além da entrega, o que os usuários realmente querem é não publicar algo que será rejeitado. Isso significa codificar por plataforma:
- Limites de caracteres
- Quantidades, tamanhos, formatos, durações e proporções de mídia
- Quais tipos de publicação exigem mídia
- Quais formatos existem
E validar na criação em vez de na publicação, porque uma falha no momento da publicação é algo que o usuário descobre depois que o momento já passou.
Construa se
- Você publica em exatamente uma plataforma, permanentemente
- A publicação é o seu produto e o diferencial
- Você precisa de profundidade muito além da publicação, como gestão de anúncios
Não construa se
A publicação é um recurso de algo maior que você está construindo e alcança três ou mais plataformas. O custo não é a construção, é a manutenção, e a manutenção escala com o número de plataformas enquanto sua equipe não escala.
A alternativa
Uma única integração, em que a instabilidade das plataformas é problema de outra pessoa.
- URL base:
https://app.bulkpublish.com - Autenticação: chave de API, ou OAuth 2.1 se você agir em nome das contas dos seus usuários
- Superfície: 59 endpoints documentados
- Plataformas: 15
- Validação: limites verificados na criação, não na publicação
- SDKs: Node e Python, além de uma coleção do Postman e um servidor MCP
| Free | Pro | Business | |
|---|---|---|---|
| Requisições de API/dia | 30 | 5.000 | 50.000 |
| Chaves de API | 1 | 5 | 10 |
Em resumo
A fila é um fim de semana. Os estados, os fusos horários, e um fluxo OAuth mais um job de atualização mais um pipeline de mídia por plataforma são o projeto de verdade, e a instabilidade das plataformas significa que ele nunca termina. Construa se a publicação é o seu produto ou se você vai ficar em uma única plataforma para sempre. Caso contrário, a integração que você não mantém vale mais do que a que você mantém.