Que explicação incrível!! Mandou demais mesmo.... estava pesquisando há um bom tempo já, e não tinha conseguido entender de fato a necessidade disso. Agora, tudo faz sentido!! Obrigado
@@attekitadev ola poderia fazer um vídeo aprofundando, sobre BFF focado em deploy fornecendo dados de montagem de UI. Isso e revolucionário!!!!! Por favor, faça um vídeo aprofundando, até pq vc e muito didática. Obrigado por esse vídeo maravilhoso. Onde encontro mais informações sobre essa técnica? Pode me indicar algo para leitura. Você usa isso com frequência? Se associarmos isso com NoSql + Screeming Architecture (Uncle Bob) - results numa Combinação explosiva. ESSE CONCEITO EXPLODIU IDEIAS NA MINHA CABECA!!!! Mostra mais... Da pra gente um exemplo Zinho, num botão Zinho, coisa assim...
5:08 isso não acarretaria em demora na resposta da API? ou coisa mandar o servidor decidir por agrupar várias tarefas/serviços também não seria perda de desempenho? imagina ter que enviar 1 milhão de requisições pro front com todas as informações da página (botões, labels, etc) e agora 1 milhão somente com o dados com usuário e o front renderizar isso?
Muito louco pensar que já utilizei do padrão sem saber que era um padrão kkkk por exemplo, já trabalhei em uma equipe em que eu combinava com o front o que ele precisava e dessa forma eu construia a API pra ele kkkkkk
deu pra entender claramente que o usuario final e o dev front end se beneficiam bastante com isso, e qual seria o ganho do dev backend? imagino que algumas coisas seria maior relevância da sua posição (afinal ainda mais regra de negócio estaria a cargo dele) e uma maior diversidade de atividades já que agora não só envia um documento estático mas algo mais dinâmico para uma página com regra de negócio específica
Graphql pode ser um complemento na arquitetura que usa BFF. Enquanto no graphql vc vai buscar dados em diferentes fontes para montar um único output, no BFF vc leva isso para outro nível pois além de conseguir entregar exatamente o que o front precisa, você pode entregar dados estáticos também (como dito no vídeo). No fim do dia, são bem próximos, mas totalmente diferentes. BFF ta muito mais pro frontend, enquanto graphql gera benefícios para back (integrações, por exemplo) e front (contrato enxuto, por exemplo).
Então se eu quiser fazer um endpoint que busque as tags do html do meu form e fazer isso renderizar na view estaria correto? algo como ex: backend/api form:{ "button1": "Enviar" "button2": "Parar" } ------------------------------------------------------------------------------------------------------ frontend/exibir os botoes:[ form.button1; form.button2; ------------------------------------------------------------------------------------------------------- seria mais ou menos isso?
Você até pode fazer assim, mas acho que o correto seria os elementos e sua disponibilidade está no json e no mobile vc fazer as verificações necessárias para a visualização.
Que explicação incrível!! Mandou demais mesmo.... estava pesquisando há um bom tempo já, e não tinha conseguido entender de fato a necessidade disso. Agora, tudo faz sentido!! Obrigado
Ótima explicação, didática, feita de um modo claro e muito charmosa.Parabéns!
Obrigada ☺️
GraphQL Seria um tipo de BFF ? quais seriam as diferenças deles ?
Muito bom conteúdo! E você fala muito bem, com muita propriedade e desenvoltura. Adorei o vídeo. ;D
Eu já entendi Best Friend for Ever hahah quando veio a notificação :) Parabéns
😂😂😂
@@attekitadev ola poderia fazer um vídeo aprofundando, sobre BFF focado em deploy fornecendo dados de montagem de UI. Isso e revolucionário!!!!! Por favor, faça um vídeo aprofundando, até pq vc e muito didática. Obrigado por esse vídeo maravilhoso. Onde encontro mais informações sobre essa técnica? Pode me indicar algo para leitura. Você usa isso com frequência? Se associarmos isso com NoSql + Screeming Architecture (Uncle Bob) - results numa Combinação explosiva. ESSE CONCEITO EXPLODIU IDEIAS NA MINHA CABECA!!!! Mostra mais... Da pra gente um exemplo Zinho, num botão Zinho, coisa assim...
5:08 isso não acarretaria em demora na resposta da API? ou coisa mandar o servidor decidir por agrupar várias tarefas/serviços também não seria perda de desempenho? imagina ter que enviar 1 milhão de requisições pro front com todas as informações da página (botões, labels, etc) e agora 1 milhão somente com o dados com usuário e o front renderizar isso?
Obrigado pela ótima explicação! Adorei seu cabelo tbm, incrível
Obrigada ☺️
Ótima explicação, muito clara e fácil de entender. Parabéns!
Parabéns pela objetividade e clareza das informações.
Obrigado pelo video ! Sugestão, diminuir a musica :)
Abraço !
Muito louco pensar que já utilizei do padrão sem saber que era um padrão kkkk por exemplo, já trabalhei em uma equipe em que eu combinava com o front o que ele precisava e dessa forma eu construia a API pra ele kkkkkk
né
Mas qual a diferença entre BFF e APIGateway?
deu pra entender claramente que o usuario final e o dev front end se beneficiam bastante com isso, e qual seria o ganho do dev backend? imagino que algumas coisas seria maior relevância da sua posição (afinal ainda mais regra de negócio estaria a cargo dele) e uma maior diversidade de atividades já que agora não só envia um documento estático mas algo mais dinâmico para uma página com regra de negócio específica
Explicação perfeita!
Attekita, qual a origem do seu nome Bullas?
Best friend for ever, kkkkk. Video bacana, valeu Attekita.
adorei d+ esse conceito, vou criar algum projeto em cima disso
ué, mas todos estes problemas não seriam resolvidos com GraphQL ?
Graphql pode ser um complemento na arquitetura que usa BFF. Enquanto no graphql vc vai buscar dados em diferentes fontes para montar um único output, no BFF vc leva isso para outro nível pois além de conseguir entregar exatamente o que o front precisa, você pode entregar dados estáticos também (como dito no vídeo). No fim do dia, são bem próximos, mas totalmente diferentes. BFF ta muito mais pro frontend, enquanto graphql gera benefícios para back (integrações, por exemplo) e front (contrato enxuto, por exemplo).
Aeeeee. Aprendi aqui o que era BFF.
Excelente
finalmente entendi vlw
Amei obg
Fera. Profissa.
Eu tenho uma melhor, bastidores do free fire.
Hahahahha boaa
Amei!!!
Perfeito!!! 👏👏👏👏
Então se eu quiser fazer um endpoint que busque as tags do html do meu form e fazer isso renderizar na view estaria correto?
algo como ex:
backend/api
form:{
"button1": "Enviar"
"button2": "Parar"
}
------------------------------------------------------------------------------------------------------
frontend/exibir os botoes:[
form.button1;
form.button2;
-------------------------------------------------------------------------------------------------------
seria mais ou menos isso?
Você até pode fazer assim, mas acho que o correto seria os elementos e sua disponibilidade está no json e no mobile vc fazer as verificações necessárias para a visualização.