React: Repository pode acessar uma API?

[@mthsena]

Meu raciocínio sobre repository é bem nessa linha que você citou Branas. O repository não quer saber como a persistência é feita, desde que o objetivo seja persistência de objeto de domínio, assim faz muito sentido repository chamar api ou qualquer outro tipo de serviço que esteja no mesmo contexto.

[@gsevla]

eu concordo demais. principalmente pelo que foi dito no final. tendemos a respeitar a interface do repository, que, por sua vez, respeita do domínio da aplicação, então não importa de onde vem o dado, o repository vai caber... não tem sentido dizer que o repository é exclusivo de banco de dados

[@akaleozinn]

comentario fora do contexto: to gostando demais do branas low profile, espero que essa fase dure bastante, só gratidão pelas dicas de tecnologia!!!

[@RodrigoBranas]

Obrigado meu amigo, to tentando ir numa linha mais simples, direta... menos procrastinação... valeu!!

[@HugoUragaa]

Sensacional, Branas. Ótimo contéudo!

[@RodrigoBranas]

valeu amigo!!

[@leandromartinz2]

Análise perfeita.

[@RodrigoBranas]

Obrigado!!

[@douglaspoma]

Seria interessante mostrar isso em um caso real, exemplo um DB da AWS que vc acessar via SDK ou mesmo web API.

[@manoellopes211]

No Back chamo de UseCases e Repositories, no Front Chamo Services e Gateways

[@_Gabriwl_]

Um caso, é o meu, atualmente cuido de um software de integrações, basicamente temos o produto principal (outra equipe) e o cliente tem outro ERP que ele quer unir, o meu projeto cuida da integração desses dados entre os dois ERP's, e para fazer o CRUD no meu banco, por razões de negócio (replicar tudo que a API do software principal faz é inviável), a gente faz a persistência via API, então para gente, nosso repository, são HTTP requests enviado no end-points da API do software principal

[@arozendojr]

conceito de /health no backend, verifica a saude do contêiner, como podemos fazer a mesma coisa no contêiner do front, o que é mais usado no mercado em relação ao /health para frontend ?

[@madruguinhadocs]

Passando aqui pra fortalecer no like. Esses novos conteúdos focados em ddd estão tops.

[@tfuhlol]

Sou da epoca do AngularJS, seu conteudo é muito bom mano. Pretende fazer algum curso do Angular atual? aprendi mt com vc

[@cleytongama]

Excelente, concordo; Por exemplo, ao usar o S3 da AWS para armazenamento, o repositório interage diretamente com a API do S3. Isso mostra que um repositório pode se adaptar a diferentes meios de persistência, mantendo sua função essencial de mediar entre o modelo de domínio e a camada de dado; Neste contexto, atua como uma interface abstrata que esconde os detalhes de implementação e interage com o S3 através de sua API

[@kztnied]

meu palpite é que este cenário só se torna válido quando você abstrai totalmente a forma em que este repositório consegue persistir/consultar dados. E que esses dados representam dados não necessariamente relacionados ou cruzados com outro domínio da aplicação que realizou o procedimento

[@stharleymaxwell7081]

Considerando a construção de um micro serviço, que tem como responsabilidade salvar um dado em um CRM. Entendo que nesse caso o registro ali é minha entitu, certo? Esse dado que estou mapeando é construindo na domain model. Seria esse caso onde consumir essa API do crm poderia chamar de repository ou ja estou estrapolando?

[@micaelcosta1549]

Boa tarde. Antes de mais, parabéns e obrigado pelo um excelente conteúdo que fornece gratuitamente aqui no youtube. Gostaria de colocar uma dúvida que tenho andado estes últimos dias a tentar esclarecer e que não estou a chegar a nenhuma conclusão. O fluxo normal de uma ação de um utilizador será ui -> Caso de uso -> criar ou obter objetos de dominio e por fim se existir essa necessida chamar um repositório para guardar as alterações feitas num objeto de dominio. Sendo este o fluxo normal quando desenvolvo um aplicação começo por desenvolver o dominio e posteriormente os casos de uso, contudo neste último devido a alguma formações e videos que vi dizem que um caso de uso não é representativo de frontend ou backend e desta forma a implemtação deve ser sempre a mesma. Dando um exemplo, pretendo fazer um contador, teria um Contador como entidade e teria um repositório para o contador para guardas as alterações que sejam feitas nele. Caso um utilizador queira incrementar o valor do contador chamaria um caso de uso Incrementar com o id do contador como parametro, o caso de uso tenta obter o contador através do repositório, altera chama a função incrementar da entidade e depois volta a guardar as alterações através do repositório e o caso de uso ficaria completo e não está importado que tipo de aplicação está a usar este caso de uso, se uma api, se uma aplicação frontend react ou vue, o caso de uso deveria ser o mesmo. (Aqui uma dúvida que tenho é se realmente o caso de uso seria o mesmo para frontend e backend) Caso o caso de uso possa ser o mesmo, ao tentar implementar isto num frontend utilizando por exemplo react e pensando que tenho um repositório, o que seria este repositório? Poderia ser um repositório em memória ou uma chamada a uma api, mas sendo um repositório em memória, faz sentido guardar dados no repositório e guardar dados num useState do react pois sempre que incrementa um valor a página do react deve ser atualizada? Esta dúvida é um pouco extensa e não sei até que ponto teria um tempo para a responder num possível video ou mesmo respondendo aqui mas ajudaria-me imenso a ver este tema que me tem desgatado porque não consigo encontrar uma resposta para este situação. A única forma que é vejo de fazer isto é ter casos de uso especificos para frontend e backend e o frontend não teria o caso do repository e sim, sempre que é necessário alterar uma determinada infromação que não necessite de aceder a uma api, que apenas faça uma alteração em memória, os dados ficariam guardados no react e o caso de uso receberia um objeto de domino, mas isto também deixa de fazer sentido porque o caso de uso já seria o próprio componente do react e ele mesmo interagia com os objetos de domino. Se conseguir responder ficaria muito agradecido ;)

[@isakielsouza]

Branas to sem rede social, coloca aqui tb os videos. obg em breve estarei em uma de suas terumas

[@app2028]

🎉🎉🎉 você e lendário 🎉🎉🎉 seus vidoes e peojrtos a anos ❤🎉

[@RodrigoBranas]

obrigado irmão!!

[@arozendojr]

Já vi o PostgreSQL ter o recurso de API, ao meu ver seria o melhor caso do uso do repository consumindo uma API.Acho que é PostRest, pensando o comportamento será de um repository ok. Contudo ou usar repository ou usar Gateway. Ao meu ver Usecase->Repository->Gateway não estaria certo. O que acha ?

[@RodrigoBranas]

O Repository poderia usar o Gateway, sem problemas, assim como poderia usar um DAO para acessar uma tabela. Faz sentido! Abraços!

[@arozendojr]

@@RodrigoBranas pensava se no final será usado gateway, seria melhor não usar o repository no meio. Agora estava pensando em que situação usa o gateway direto, Usecase->gateway ?

[@LarutanAK]

Um repository acessar uma API, pelo menos pra mim, demonstra um anti-pattern profundo. A primeira pergunta que eu faria: pq fazer um repository acessar uma API ao invés de acessar uma API via service que, por fim, realiza a persistência? Uma segunda pergunta: se eu preciso realizar operações alheias à persistência, pq não fazer isso na camada de negócio antes de tentar a persistência? Apesar de que, na teoria, a idéia de utilizar um repository é abstrair a camada e não ter a necessidade de saber o que acontece, apenas que aconteceu, fazer essa interpretação elástica permitindo um repository acessar uma API pra então realizar a persistência é criar mais pontos de falha, aumentando a complexidade do sistema, do seu desenvolvimento e do rastreamento de falhas. Em suma - um repository não se conectar diretamente com a persistência me parece firula desnecessária, apesar de, pragmaticamente falando, ser válido.

[@RodrigoBranas]

é como eu falei no vídeo, o papel do repository é mediar a relação entre o domain model e a persistência, se ela será acessada por uma conexão com o banco de dados, uma api com o banco de dados, um file system ou na memória, isso não interfere no padrão, não interfere na persistência dos aggregates, persistir o estado, recuperar o estado

[@vibedev.official]

Resumindo, este é o problema de videos curtos(shorts), você não consegue dar estes detalhes para explicar um conceito em detalhes.

[@RodrigoBranas]

pois é, mas também dá pra chegar em bastante gente que não tem paciência pra assistir 2 horas de vídeo, as vezes é a construção de um caminho, começa lá, continua aqui. Valeu!!

[@vibedev.official]

@@RodrigoBranas Com certeza! Não tiro sua razão, minha critica nem é para você, mas sim, sobre esta cultura de conteúdo rápido para consumo. Acaba deixando tudo muito superficial! Mas, independente disso, seu conteúdo é excelente e concordo plenamente com o que você abordou.

[@RodrigoBranas]

@@vibedev.officialobrigado meu amigo!!

[@newbee1816]

Galera, sei que não tem muito a ver com o assunto, mas gostaria de uma orientação. Recentemente, trabalhei nos sistemas de uma empresa que possui APIs distribuídas, sendo que uma API consome informações de outras da mesma empresa. Dentro dessas APIs havia vários códigos espalhados com as chamadas para essas APIs internas, então, eu criei uma biblioteca (artefato do Azure DevOps) e estou colocando esse código dentro dessa biblioteca, de forma a ter uma classe base, que faz as requisições e devolve as respostas. É uma boa prática ?

[@zilondequadrosmaciel1006]

Branas, faz mais vídeos, com tema DDD e TDD, um abraço, você é fera.

[@RodrigoBranas]

com certeza!! valeu amigo!!

[@thales-maciel]

fazer chamada http pro banco é chamar uma api

[@pedroaugustogti]

Se o repository não for exclusivo para o banco de dados eu poderia fazer uma chamada externa de dentro dele para outra API para complementar os dados de uma consulta do banco de dados. Sendo que essa chamada externa poderia ficar na camada anterior de service, e se precisace de alguma lógica pra montar o objeto pra devolver pro gateway ou controller ficaria em uma camada para melhor refactor.

[@principe.borodin]

Eu tenho a primeira edicao desse livro do martiwn fowler, em portugues, e nem tem essa capinha preto e vermelha 🤭🤭🤭🤭

[@RodrigoBranas]

antigo eim!!

[@principe.borodin]

@@RodrigoBranas antigo nao, raro, uma vez que mandei email para o proprio solicitando nova reimpressao dos livros ja esgotados, e ele negou, mandando ler o site.

[@LeonardoFurtado-u1g]

mas esse livro tem essa capa desde a primeira edição, o que vc pode ter é uma versão diferente, mas a edição é a mesma. Ou você tem o outro livro dele, que tinha uma versão branca e depois mudou pra uma preta e vermelha, mas o título do livro é diferente.

[@principe.borodin]

@LeonardoFurtado-u1g negativo

[@LeonardoFurtado-u1g]

@@principe.borodin se vc abrir o site desse livro na primeira edição a capa dele é preta e vermelha.