IV. Backing Services – Tratar serviços de apoio como recursos anexados

O código para um aplicativo de doze fatores não faz distinção entre serviços locais e de terceiros. Para o aplicativo, ambos são recursos anexados, acessados ​​por meio de uma URL.

4º Fator: Tratar Serviços de Apoio (Backing Services) como Recursos anexados

O quarto fator da metodologia de doze fatores foca na maneira como a aplicação interage com serviços de apoio (backing services). Um serviço de apoio é qualquer serviço que a aplicação consome por meio da rede como parte de sua operação normal, e que pode ser trocado ou substituído sem impactar diretamente o código da aplicação. Exemplos incluem bancos de dados, sistemas de cache, filas de mensagens e APIs externas.

No contexto de desenvolvimento moderno, especialmente ao trabalhar com frameworks como Angular, serviços como Firebase, Keycloak, OAuth, e integrações com APIs RESTful ou GraphQL também são vistos como serviços de apoio. Esses serviços podem ser locais, rodando no mesmo ambiente que a aplicação, ou gerenciados por terceiros, fornecidos como serviços na nuvem.

Cada serviço de apoio distinto é um recurso.

O Que São Backing Services?

Backing services são componentes externos que suportam a aplicação, mas que não fazem parte do código principal. Eles incluem:

• Bancos de dados: MySQL, PostgreSQL, MongoDB.
• Sistemas de cache: Redis, Memcached.
• Filas de mensagens: RabbitMQ, Kafka.
• APIs externas: APIs RESTful, serviços GraphQL, APIs de terceiros.
• Sistemas de autenticação: Firebase Authentication, Keycloak, OAuth.
• Serviços de armazenamento: Amazon S3, Firebase Storage.

Na metodologia dos doze fatores, a aplicação deve tratar esses serviços de forma desanexada (ou desacoplada). Ou seja, a aplicação não deve depender diretamente da infraestrutura específica de um serviço de apoio. Em vez disso, a aplicação deve acessar esses serviços por meio de URLs, credenciais ou endpoints configurados no ambiente, o que permite que o serviço seja substituído ou redirecionado sem a necessidade de alterar o código da aplicação.

Firebase, Keycloak, OAuth como Backing Services

No ecossistema Angular, serviços como Firebase, Keycloak e OAuth desempenham papéis fundamentais na autenticação e gerenciamento de identidade, sendo exemplos claros de backing services:

• Firebase: Oferece uma variedade de serviços, incluindo autenticação, banco de dados em tempo real, armazenamento de arquivos, e notificações push. Como um serviço gerenciado por terceiros, ele pode ser facilmente integrado a uma aplicação Angular usando SDKs fornecidos pelo Firebase. A aplicação Angular interage com o Firebase por meio de APIs, e todas as credenciais e endpoints são configurados externamente, permitindo que o Firebase seja substituído por outro serviço de backend sem alterar o código da aplicação.
• Keycloak: Um sistema de gerenciamento de identidade e acesso open-source, usado para autenticar e autorizar usuários em aplicações web. O Keycloak é um serviço desacoplado, que pode ser hospedado localmente ou gerenciado em um servidor de terceiros. A aplicação Angular interage com o Keycloak por meio de tokens JWT ou OAuth, e as credenciais de acesso são configuradas no ambiente, sem depender diretamente do código da aplicação.
• OAuth: O OAuth é amplamente utilizado para delegar autenticação e autorização entre serviços. Em uma aplicação Angular, o OAuth pode ser integrado para permitir login de usuários por meio de plataformas externas, como Google, Facebook ou GitHub. A aplicação trata o OAuth como um serviço de apoio, utilizando endpoints externos para autenticação e recebendo tokens de acesso, sem saber detalhes sobre o provedor OAuth subjacente.

Integração com APIs RESTful e GraphQL

Além dos serviços de autenticação e armazenamento, a aplicação Angular geralmente se comunica com APIs RESTful ou GraphQL para buscar dados ou enviar informações. Essas APIs também são backing services, e a aplicação deve tratá-las como recursos desanexados.

• APIs RESTful: Uma aplicação Angular faz requisições HTTP a endpoints RESTful, como GET /users ou POST /orders. A URL do endpoint, as credenciais de autenticação e outras configurações são definidas no ambiente, garantindo que a API possa ser alterada ou redirecionada (por exemplo, de um servidor de desenvolvimento para um servidor de produção) sem mudanças no código da aplicação.
• GraphQL: O uso de GraphQL está crescendo como uma alternativa ao REST, permitindo que a aplicação Angular faça consultas mais flexíveis. A integração do Angular com uma API GraphQL segue os mesmos princípios de desacoplamento: a aplicação não sabe onde ou como a API GraphQL está hospedada, ela apenas consulta um endpoint configurado externamente.

A abordagem desacoplada permite que as APIs RESTful ou GraphQL sejam hospedadas localmente em um ambiente de desenvolvimento e depois substituídas por APIs gerenciadas na nuvem em produção, sem alterações no código.

Mockagem de Backing Services em Desenvolvimento

Durante o desenvolvimento de aplicações Angular, muitas vezes não é prático ou seguro interagir com backing services reais. Nesse caso, é comum utilizar mockagem para simular o comportamento desses serviços sem depender de uma infraestrutura externa.

• Mock APIs: APIs RESTful ou GraphQL podem ser mockadas em desenvolvimento para simular as respostas que seriam recebidas de um backend real. Ferramentas como json-server ou Mockoon permitem criar APIs falsas rapidamente, possibilitando que os desenvolvedores trabalhem de forma produtiva sem precisar de um ambiente backend configurado.
• Mock de autenticação com Keycloak ou OAuth: Em vez de configurar sistemas de autenticação reais, pode-se simular as respostas de serviços como Keycloak ou OAuth em ambientes de desenvolvimento. Isso permite que os desenvolvedores testem a lógica de autenticação sem acessar servidores externos.

A mockagem é particularmente útil em testes automatizados, onde o ambiente deve ser totalmente controlado e previsível. Ao simular os backing services, é possível testar o comportamento da aplicação Angular sem depender de serviços externos, garantindo que os testes sejam rápidos e confiáveis.

Benefícios de Tratar Backing Services como Recursos Desanexados

1. Flexibilidade: Ao desacoplar a aplicação dos backing services, é possível alterar ou substituir esses serviços sem afetar o funcionamento da aplicação. Por exemplo, você pode mudar de um banco de dados local para um gerenciado na nuvem ou trocar um provedor OAuth sem alterar o código da aplicação.
2. Escalabilidade: Em produção, muitos backing services (como bancos de dados ou APIs) são gerenciados por terceiros na nuvem. Tratar esses serviços como desanexados permite que a aplicação escale facilmente, sem precisar gerenciar a infraestrutura subjacente.
3. Portabilidade: Uma aplicação Angular que segue este princípio pode ser implantada em qualquer ambiente (desenvolvimento, homologação, produção) simplesmente mudando as variáveis de ambiente, como URLs e credenciais de serviços de apoio. Isso facilita a migração entre diferentes plataformas de hospedagem.
4. Testabilidade: Ao simular ou mockar backing services durante o desenvolvimento, é possível isolar a aplicação Angular e testar seu comportamento sem precisar de serviços reais em funcionamento. Isso aumenta a confiabilidade dos testes e acelera o desenvolvimento.

Conclusão

Tratar serviços de apoio como recursos desanexados é fundamental para garantir a flexibilidade, escalabilidade e testabilidade de uma aplicação Angular. Firebase, Keycloak, OAuth, e APIs RESTful ou GraphQL são exemplos de serviços de apoio que podem ser integrados à aplicação de forma desacoplada, permitindo que sejam substituídos ou redirecionados sem mudanças no código.

Além disso, o uso de mockagem durante o desenvolvimento permite que a equipe trabalhe de maneira eficiente, simulando backing services sem depender de infraestrutura externa, o que aumenta a agilidade do processo de desenvolvimento e garante que a aplicação seja facilmente testada e mantida.