2:10 - só uma observação, na tela aparece "Overfitting e Underfitting", mas acredito que o correto, assim como ela cita no vídeo, seja "Over-fetching e Under-fetching".
Bacana! O front especifica exatamente o que precisa, isso pode até onerar um pouco o back ao ter esse processamento para "correr atrás" do que foi solicitado, mas deixa a transmissão de dados mais leve. Vejo isso quando o cliente está com um smartphone na rede de dados (3G, 4G, etc...) e faz com que sejam economizados os dados a serem devolvidos para a aplicação nesse caso. Economiza banda.
Uma alternativa a isso é a criação de um BFF (back for front) correto? Que faz essa coleta de informações de N endpoints e envia tudo formatado para o front. Fazendo a verificação de autorizações de acesso canal para a resposta etc correto?
Fala ai Leo, tudo bem? Não temos um curso focado em RPA, mas talvez estas indicações podem ajudar você: cursos.alura.com.br/category/infraestrutura#embarcados cursos.alura.com.br/category/infraestrutura#internet-das-coisas Inclusive, se quiser sugerir este curso, fica a vontade. É só preencher esse form aqui embaixo: docs.google.com/forms/d/e/1FAIpQLScwKyaSvuFXK9SmMJoLPuYAS2qD_XAAnZPxMZij9qVeflbhBg/viewform Esperamos ter ajudado!
Cara, não vou dizer que é sofrido, mas a dependender da quantidade de chamadas que você precisa fazer as vezes pra montar um modelo único, chamar duas API's em cascata eu já começo a ver como um problema, ainda mais usando observable... Vira uma diarréia só usando o padrão REST. Cara, pra mim faz todo o sentido migrar pro graphQL, ainda mais sabendo que uma única chamada limaria o problema de multiplas chamadas usando observables, o que dá uma baita dor de cabeça pra resolver.
estou estudando o graph ql achei mto interesante principalmente pq trabalha muito bem com real time msm nao usando sokets mais, ainda acho meio confuso, parece que ele ta fazendo meio que tudo e deixando igual o paulo falo o backend burro , se ele ja faz toda essa busca pq por ex precisaria de um controller por ex ainda fico meio perdido nessa parte
kkkkk de uma época pra cá parece que estamos procurando "pelo em ovo", ficamos criando "linguagem" e estruturas definidas pra qualquer abordagem que antes era apenas conceitual.... ou seja, tudo, absolutamente tudo vira linguagem nova! pra mim isso não vai dar certo a longo prazo pois vai pulverizando tanto que não se tem base de nada!
2:10 - só uma observação, na tela aparece "Overfitting e Underfitting", mas acredito que o correto, assim como ela cita no vídeo, seja "Over-fetching e Under-fetching".
Bacana!
O front especifica exatamente o que precisa, isso pode até onerar um pouco o back ao ter esse processamento para "correr atrás" do que foi solicitado, mas deixa a transmissão de dados mais leve.
Vejo isso quando o cliente está com um smartphone na rede de dados (3G, 4G, etc...) e faz com que sejam economizados os dados a serem devolvidos para a aplicação nesse caso. Economiza banda.
Opa! Vim aqui por conta da formação React: Consumindo APIs. Agradeço essa introdução ao GraphQL. Agora bora para mais um curso com o Vinny!
Caraca, eu tô estudando a 50 minutos sobre GraphQL... O bagulho já me explodiu a cabeça e tô com vontade de aplicar em todos os meus projetos
Muito bom! Deu para entender bem o conceito! Show!
Abriu de mais minha mente.
Ficamos felizes que tenha te ajudado, Jefferson ! 💙Conte conosco! 👏😊
A didatica da Ju é incrível ❤😮
Bom demais saber que você tá curtindo, ela é incrível mesmo💙✨
Muito bom o vídeo, bem explicado.
Instrutivo. Valeu Juliana.
Uma alternativa a isso é a criação de um BFF (back for front) correto? Que faz essa coleta de informações de N endpoints e envia tudo formatado para o front. Fazendo a verificação de autorizações de acesso canal para a resposta etc correto?
O BFF é apenas um conceito, na vdd você pode criar um BFF que utiliza o GraphQL.
Usamos Nestjs e oq ele sugere para os endpoinsts
Finalmente alguém que fala "sintaxe" corretamente!!! Kkk
Hoje usamos bff's pra fazer essa agregação, da para deixar a request mais rica ou remover campos desnecessário para front/mobile
Na alura tem cursos de RPA? Ensinando ferramentas como o UiPath ou usando a linguagem python? Tbm poderia ter uns podcast sobre RPA no hipsterstech..
Fala ai Leo, tudo bem? Não temos um curso focado em RPA, mas talvez estas indicações podem ajudar você:
cursos.alura.com.br/category/infraestrutura#embarcados
cursos.alura.com.br/category/infraestrutura#internet-das-coisas
Inclusive, se quiser sugerir este curso, fica a vontade. É só preencher esse form aqui embaixo:
docs.google.com/forms/d/e/1FAIpQLScwKyaSvuFXK9SmMJoLPuYAS2qD_XAAnZPxMZij9qVeflbhBg/viewform
Esperamos ter ajudado!
Cara, não vou dizer que é sofrido, mas a dependender da quantidade de chamadas que você precisa fazer as vezes pra montar um modelo único, chamar duas API's em cascata eu já começo a ver como um problema, ainda mais usando observable... Vira uma diarréia só usando o padrão REST. Cara, pra mim faz todo o sentido migrar pro graphQL, ainda mais sabendo que uma única chamada limaria o problema de multiplas chamadas usando observables, o que dá uma baita dor de cabeça pra resolver.
O GraphQL é legalzinho, mas não vejo essa animação toda que tanta gente mostra quando fala dele
Poxa vida, cara. Give me the simple life. Os caras tão inchando uma parada que é simples
fala sobre federation
estou estudando o graph ql achei mto interesante principalmente pq trabalha muito bem com real time msm nao usando sokets mais, ainda acho meio confuso, parece que ele ta fazendo meio que tudo e deixando igual o paulo falo o backend burro , se ele ja faz toda essa busca pq por ex precisaria de um controller por ex ainda fico meio perdido nessa parte
omg
kkkkk de uma época pra cá parece que estamos procurando "pelo em ovo", ficamos criando "linguagem" e estruturas definidas pra qualquer abordagem que antes era apenas conceitual.... ou seja, tudo, absolutamente tudo vira linguagem nova! pra mim isso não vai dar certo a longo prazo pois vai pulverizando tanto que não se tem base de nada!
Mais uma porcaria para os devs saírem correndo atrás para estudar, TI é só isso