Integração e API
Plugin API
Na arquitetura extensível, a Plugin API define o limite entre o núcleo e módulos carregáveis. Ela especifica hooks, interfaces, eventos, permissões, ciclo de vida e compatibilidade. Home Assistant integra componentes por manifestos e APIs; WordPress usa actions e filters; Gradle aplica `Plugin<T>`. Um plugin conversa com o host, não diretamente com todos os demais. O critério de escolha é estabilidade pública: usar APIs internas reduz trabalho inicial, mas aumenta quebras em atualizações.
🔀 Tipos de Comunicação
HOOKS
Hooks de evento e filtro
O host publica pontos nomeados em momentos específicos. Plugins registram callbacks. WordPress diferencia actions, que executam efeitos, e filters, que recebem e retornam valores. Uma plataforma de automação pode emitir `device_added`, `state_changed` ou `automation_executed`. O contrato precisa definir ordem, argumentos, retorno e tratamento de exceção. Prioridades podem alterar resultado. Dois plugins podem modificar o mesmo valor. Reentrância e loops são riscos. Um callback lento bloqueia o host se a API for síncrona. APIs modernas oferecem eventos assíncronos ou filas. O plugin deve remover listeners no unload para evitar vazamento. Hooks não são um barramento sem governança; nomes e payloads precisam de versão.
INTERFACE
Interfaces e serviços registráveis
A Plugin API pode exigir que a extensão implemente uma interface, como `Plugin<T>.apply(target)` no Gradle, ou registre serviços. O host chama métodos padronizados: inicializar, iniciar, parar, configurar e diagnosticar. O plugin pode fornecer novos tipos de dispositivo, ações, painéis ou conectores. Interfaces tipadas detectam erros em compilação. APIs dinâmicas dependem de testes. O contrato deve dizer quais métodos podem ser chamados em paralelo e quais objetos permanecem válidos. O plugin não deve guardar referências internas além do ciclo de vida. Compatibilidade semântica importa: manter a mesma assinatura enquanto muda o efeito também quebra.
MANIFEST
Manifesto, metadados e descoberta
Plugins são identificados por ID, versão, dependências, permissões e versão mínima do host. Home Assistant usa `manifest.json` para domínio, documentação, requisitos, dependências, discovery e qualidade. Navegadores usam manifestos de extensões. O host lê antes de carregar. Isso permite rejeitar incompatibilidade e resolver dependências. O manifesto precisa ser validado. IDs são estáveis. Versões seguem convenção como SemVer quando adotada. Dependências transitivas aumentam risco. O carregamento não deve executar código antes de verificar assinatura e política quando a plataforma oferece. Um arquivo de metadados não é sandbox; permissões precisam ser aplicadas pelo runtime.
UI
API de frontend e painéis
Plugins podem registrar páginas, cartões, widgets ou painéis. Home Assistant permite custom panels com acesso em tempo real ao objeto da aplicação. WordPress oferece APIs administrativas e de blocos. O host precisa fornecer componentes, temas, tradução e roteamento. A extensão não deve manipular DOM interno não documentado, porque atualizações quebram. Content Security Policy, isolamento, sanitização e permissões são necessários. Um painel pode expor câmeras, presença e fechaduras; o backend deve autorizar cada dado, não confiar na visibilidade do menu. A API de UI precisa ter versionamento e fallback. Recursos visuais não devem bloquear o núcleo se falharem.
✅ Vantagens Arquiteturais
⚡
Amplia a plataforma sem alterar o código central
O plugin é instalado, habilitado e removido separadamente. Isso reduz forks e facilita atualização do núcleo. A condição é que a API pública cubra o caso. Quando a extensão precisa patchar arquivos internos, perde-se o benefício. O host deve oferecer pontos suficientes sem expor tudo. Plugins podem ser oficiais, comunitários ou comerciais. A governança precisa distinguir. Assinatura, revisão e repositório ajudam. Em uma casa, um plugin para inversor solar pode adicionar integração sem esperar a próxima versão do núcleo. Se for abandonado, a automação fica dependente. O inventário deve registrar autor, versão e alternativa.
⚡
Cria ecossistema de integrações reutilizáveis
Uma API estável permite que terceiros suportem marcas e protocolos. WordPress cresceu por hooks; Gradle por plugins; Home Assistant por integrações e custom components. Reutilização reduz desenvolvimento duplicado. A qualidade varia. O diretório ou store precisa de critérios, testes e informações de compatibilidade. Downloads não equivalem a segurança. O usuário deve avaliar manutenção recente, issues e permissões. Uma plataforma com dez mil extensões pode exigir mais curadoria que outra com cem integrações oficiais. Quantidade não é o único critério. Para automação crítica, suporte e testes pesam mais.
⚡
Separa domínios e reduz o tamanho do núcleo
Recursos opcionais permanecem fora do processo de desenvolvimento central. O núcleo define scheduler, estado, eventos e segurança; plugins implementam fabricantes. Isso reduz complexidade, mas pode apenas deslocá-la. APIs precisam evitar duplicação de código entre plugins. SDKs e bibliotecas comuns ajudam. Dependências não devem conflitar. Em runtimes Java, classloaders isolam; em Python, pacotes compartilham ambiente com regras. Containers ou processos externos aumentam isolamento. A escolha afeta memória e latência. Um plugin carregado no mesmo processo pode derrubar o host; um plugin externo precisa de IPC.
⚡
Permite evolução independente com contratos públicos
Host e plugin podem lançar versões diferentes se respeitam a compatibilidade. Depreciações precisam de aviso, período e ferramenta. Gradle documenta APIs públicas e alerta que APIs internas podem quebrar. Esse princípio vale para automação. O plugin deve usar apenas símbolos suportados. O host pode oferecer feature detection e versão mínima. Testes de matriz verificam host atual e próximo. O custo é manter camadas antigas. Uma depreciação eterna paralisa evolução. Política clara permite. Usuários precisam saber antes de atualizar se um plugin crítico é incompatível.
⚡
Estabelece limites de permissão e responsabilidade
Uma Plugin API pode fornecer escopos: ler estados, controlar dispositivos, acessar rede, registrar UI. O plugin deve pedir o mínimo. Em sistemas sem sandbox, essas permissões são apenas informativas. Código Python ou PHP pode acessar arquivos e rede do processo. A implantação precisa tratar plugin como código confiável. Containers, usuários de sistema e assinatura reduzem. Logs devem indicar qual plugin executou ação. Um plugin de tema não deveria destravar porta. O host precisa validar autorização no serviço, não apenas na UI. A extensibilidade aumenta a superfície de ataque e precisa de política.