A engenharia por trás do produto, sem expor a operação.
Exibição pública de contratos, arquitetura e componentes selecionados da BunnyFy, não uma distribuição do backend privado.
VITRINE TÉCNICA · PÚBLICA
[**Site público**](https://bunnyfy-dimeo.dgreych-domo.workers.dev/) · [**Plataforma Shogun**](https://shogun-dimeo.dgreych-domo.workers.dev/)
| Área | Descrição |
|---|---|
| Propósito | Contratos claros entre serviços |
| Experiência | Arquitetura com módulos desacoplados |
| Engenharia | Exemplos de capacidades, testes e documentação |
Important
Esta vitrine não inclui o backend integral nem infraestrutura, credenciais e recursos operacionais privados.
Documentação técnica completa · comandos, configuração, decisões e histórico
Media in. Power out.
Uma camada de processamento de mídia, IA e experiências visuais pensada para produtos que precisam fazer mais com menos acoplamento.
Produto • Capacidades • Arquitetura • Código público • Segurança
[!IMPORTANT] Este repositório é uma vitrine comercial e técnica da BunnyFy. Ele contém documentação, contratos, exemplos e partes selecionadas da implementação para demonstrar arquitetura e qualidade de engenharia. O backend operacional completo, infraestrutura, credenciais, configuração de produção e mecanismos privados de operação não são distribuídos por este repositório.
|
A BunnyFy concentra tarefas que normalmente acabam espalhadas entre bots, scripts, serviços externos e credenciais difíceis de governar. Em vez de cada consumidor conhecer detalhes de provedores, formatos e subprocessos, ele conversa com uma superfície única e recebe contratos previsíveis. O produto foi desenhado em torno de quatro ideias:
|
Entrada: mídia, prompt ou intenção. BunnyFy: valida, roteia, processa, observa. Saída: artefato pronto para consumo.
|
| Download, normalização e transformação de mídia por uma camada que esconde peculiaridades dos provedores e mantém erros previsíveis para os consumidores. | Renderização de cards e superfícies visuais para experiências sociais, perfis, jogos e respostas ricas sem obrigar o cliente a carregar um motor gráfico próprio. | Uma fronteira única para capacidades de IA. Modelo, provedor e credencial pertencem à plataforma; o cliente depende do contrato, não da marca por trás dele. |
| Preparação de áudio e transcrição como capacidade isolada, com indisponibilidade localizada quando uma ferramenta específica não está pronta. | Roteamento de geração e processamento visual por intenção, com possibilidade de fallback e evolução de provedores sem expor essa dança ao consumidor. | Autenticação, escopos, limites e observabilidade fazem parte da superfície da API. A integração não precisa carregar segredos dos provedores que a BunnyFy utiliza. |
flowchart LR
C[Produtos consumidores] -->|contrato BunnyFy| A[BunnyFy API]
A --> V[Validação e acesso]
V --> R[Roteamento de capacidades]
R --> M[Mídia]
R --> I[IA]
R --> S[Social Canvas]
R --> T[Transcrição]
M --> P[Adaptadores privados]
I --> P
T --> P
S --> O[Renderização local]
A --> X[Saúde · métricas · erros estáveis]
A linha que importa é simples: consumidores conhecem a BunnyFy; a BunnyFy conhece os provedores. Isso reduz credenciais espalhadas, dependência direta de terceiros e mudanças em cascata quando um fornecedor muda o próprio contrato numa terça-feira qualquer, como fornecedores adoram fazer.
O snapshot público existe para tornar a engenharia observável sem transformar o produto em uma distribuição reproduzível da operação.
| Superfície pública | O que demonstra |
|---|---|
| contratos e tipos | formato esperado entre consumidor e API |
| rotas selecionadas | organização da superfície HTTP |
| bibliotecas escolhidas | tratamento de mídia, erros e capacidades |
| testes selecionados | invariantes e comportamento esperado |
| documentação técnica | decisões de arquitetura e integração |
| exemplos visuais | direção do Social Canvas e experiências da plataforma |
Não fazem parte da distribuição pública: topologia operacional completa, credenciais, segredos, configuração real de produção, mecanismos internos de deploy, material necessário para reproduzir o serviço integral e componentes que constituem vantagem operacional da plataforma.
[!NOTE] Encontrar código neste repositório não significa que exista aqui um pacote de instalação da BunnyFy. Não há promessa de
clone → npm start → serviço completo. A finalidade é avaliação técnica e apresentação do produto.
A BunnyFy nasceu para servir aplicações reais, não para ser uma coleção abstrata de endpoints. O SHOGUN é um dos consumidores do ecossistema e usa a API como camada para capacidades que não deveriam ficar embutidas no processo do bot.
sequenceDiagram
participant App as Aplicação
participant B as BunnyFy
participant Cap as Capacidade
App->>B: requisição autenticada
B->>B: valida escopo e contrato
B->>Cap: executa ou roteia
Cap-->>B: resultado normalizado
B-->>App: resposta BunnyFy
O consumidor não precisa receber token de provedor, interpretar envelopes diferentes para cada fornecedor ou saber qual backend executou uma capacidade específica.
A arquitetura separa credenciais da plataforma de credenciais dos consumidores. Provedores externos permanecem atrás da BunnyFy; clientes recebem apenas o nível de acesso necessário ao contrato autorizado.
Falhas de ferramentas e dependências são tratadas por capacidade sempre que possível. Uma função indisponível deve produzir um erro estável e observável, não transformar a API inteira numa pilha fumegante de 500 sem contexto.
O repositório público também é tratado como uma superfície de exposição: segredos, sessões, cookies, URLs assinadas e configuração operacional real não pertencem ao snapshot público.
A BunnyFy segue em desenvolvimento ativo. O repositório público acompanha recortes selecionados da evolução técnica e visual do produto, não necessariamente cada detalhe do runtime privado no instante em que ele muda.
| API contratos tipados |
Mídia pipeline modular |
IA gateway desacoplado |
Visual Social Canvas |
Este espaço é o cartão técnico da BunnyFy: arquitetura, contratos, decisões de engenharia e exemplos suficientes para entender o que a plataforma resolve e como ela pensa, sem publicar o mapa completo da sala de máquinas.
BunnyFy
Media in. Power out.
POST /v1/downloads/instagram recebe { "url": "https://www.instagram.com/reel/<id>/" } com autenticação Bearer. A resposta contém data.items, na ordem da publicação, com tipo, dimensões e descritor de mídia. Fotos, Reels e carrosséis utilizam o mesmo contrato; vídeos são entregues em MP4 com áudio quando a publicação tem áudio. O limite é de 20 mídias, com limites de tamanho e tempo, sem transformar falhas em carrosséis incompletos.
O consumidor deve resolver media.mediaUrl relativa contra a origem da API, baixar os bytes antes da expiração e enviar a mídia no tipo correspondente. Nunca coloque a chave na URL. Stories usam o link direto /stories/usuario/id/ e dependem de estarem disponíveis e acessíveis à sessão mantida pela plataforma.
No Shogun, use !instagram <link> ou !igstory <link>. A sessão de acesso ao Instagram fica na API; cada instância do bot utiliza sua configuração BunnyFy e não precisa receber cookies do Instagram. Este repositório demonstra o contrato público; a operação da API permanece separada.