Esse papo começou comigo e com a Vivian (Gerente de Produto do Colab) entendendo melhor como poderíamos trazer mais opções de arquitetura da informação e experiência que temos em todo nosso ecossistema, com isso descobrimos que não poderíamos repensar a estrutura focada somente nas aplicações, tínhamos que abstrair o conceito de flexibilização como se fosse um serviço, desacoplado de tudo.

Pensando nisso, começamos a vislumbrar um caminho onde nós deveríamos moldar a experiência não com regras fixas, mas sim com regras que seriam flexíveis por si só, nisso nasceu o conceito do service-provider.

Ok, ok mas me explica ai o que é essa parada…

O service-provider é um conjunto de arquiteturas que vai servir para moldar a experiência do usuário baseado em determinados inputs:

Basicamente, recebemos a entidade inteira do usuário e junto com nossas outras regras flexíveis, conseguimos prover insumos necessários para que ele tenha uma experiência customizada, dependendo de onde ele esteja, quem ele seja ou em que momento ele está interfaceando conosco.

Do que é feito o service-provider?

Agora que estamos na mesma página do que o service-provider vai fazer, vamos mais fundo para entender como ele pode ser concebido.

Existe um conceito muito conhecido no mundo de desenvolvimento que são os micro serviços, que nada mais são do que funções desacopladas do nosso core para podermos ter um gerenciamento melhor. O service-provider nasceu sendo pensado em um micro serviço porém, na primeira semana, já vimos que esse modelo não iria funcionar.

Não me entenda mal, micro serviços são ótimos, mas precisávamos de algo que fosse componentizado e totalmente desacoplado da arquitetura que temos hoje, agnóstico à regra de negócio que temos hoje, que funcionasse para qualquer base code que temos ou venhamos a ter.

A pergunta óbvia é: podemos fazer isso quando trabalhamos com serviços? Evidentemente, a resposta é sim! Os serviços não têm que ser feitos de pequenos monólitos. Em vez disso, podemos ser projetados com base nos princípios SOLID, recebendo uma estrutura de componentes que suporte inclusão de novos componentes sem que se alterem componentes já existentes dentro do serviço.

O que é o S.O.L.I.D?

O S.O.L.I.D é um acrônimo que representa cinco princípios da programação orientada a objetos e design de código teorizados pelo nosso querido Uncle Bob (Robert C. Martin) por volta do ano 2000. O autor Michael Feathers foi responsável pela criação do acrônimo:

**[S]**ingle Responsibility Principle (Princípio da Responsabilidade Única)

**[O]**pen/Closed Principle (Princípio do Aberto/Fechado)

**[L]**iskov Substitution Principle (Princípio da Substituição de Liskov)

**[I]**nterface Segregation Principle (Princípio da Segregação de Interfaces)

**[D]**ependency Inversion Principle (Princípio da Inversão de Dependências)

Para quem quiser saber mais, tá aqui um ótimo artigo explicando tudo sobre SOLID.

Voltando aos serviços…

Imagine um serviço com um conjunto de classes abstratas em um ou mais arquivos. Pense em cada novo recurso ou regra de negócio como arquivos que ampliam esse serviço, nunca alterando-o, imagine que isso:

Ao serem adicionadas novas regras e princípios de negócio, se torne isso:

Perceba que as novas regras alteram o service-provider como entidade, mas não alteram os serviços que compõem anteriormente essa entidade, isso está diretamente relacionado ao Princípio da Responsabilidade Única e Princípio do Aberto/Fechado. Dessa forma, garantimos uma granularidade arquitetural dos serviços e que alteramos o serviço não alterando seu código, mas adicionando novos componentes a ele.

E no Colab, como funciona?

O modelo que pensamos não é muito diferente da arquitetura acima, vamos à sopa de letrinhas!

Todo nosso ambiente está hoje na AWS, mas isso um dia pode mudar, então além da arquitetura ser desacoplada, a infra também é, e a AWS tem um serviço que se encaixa perfeitamente nesse pensamento, as funções lambda! Funciona assim:

O service-provider nada mais é que uma organização de funções lambda (componentes da arquitetura SOLID) junto com triggers da AWS. 

Essas funções funcionam de modo independente, podendo ser chamadas em qualquer momento, por qualquer ecossistema de dentro do Colab, geralmente elas serão chamadas na autenticação do usuário e seus resultSets salvos na sessão junto com o usuário, para que sempre que precisemos mostrar uma experiência no app tenhamos insumos para sabermos como mostrar essa experiência :)