Augustão, não sei quais seus planos p/ o canal, mas cria uma aba de membros. Não sei qual o repasse do youtube p/ essa feat, mas seria massa! Ficaria feliz em ajudar, seu conteúdo é sempre mt massa.
Muito bom esse vídeo sobre vantagens em se utilizar JavaScript no backend, alguns pontos que eu anotei: - Fácil contratação, a maioria dos desenvolvedores sabem JavaScript, é uma linguagem amplamente difundida - Curva de aprendizado pequena, a empresa precisa treinar os desenvolvedores rápido, e JavaScript é uma linguagem simples, isso ajuda no onboarding ágil - Quase com certeza o frontend dos projetos serão em JavaScript, então os devs frontend também poderão ajudar no backend caso necessário As desvantagens nós já sabemos, o sort de JavaScript é completamente confuso, várias coisas em JavaScript são completamente confusas e não intuitivas (), mas JavaScript não é o único, todas as linguagens vão ter algo não intuitivo: Python com for else, que é completamente não intuitivo e mal desenhado, o tratamento de erros no Golang sem try/catch, a gestão de memória no C++, etc...
Conteúdo muito bom mano! Galera esquece que em tecnologia não existe bala de prata, pra toda escolha tem os prós e os contras. Venho de um background de JS, e usar Go está sendo muito bom, tem um ecossistema completinho e a experiência de desenvolver é muito positiva!
js? backend é php, de preferencia tudo junto com o front num mesmo arquivo .php, acessa o banco e logo em baixo bota o dado no html e vala, go horse na veia.
sai fora cara, ta falando besteira. O negócio é usar CakePHP com frontend Jquery. Toda view tem que ser mantida com JQuery e a troca de dados só com ajax que é pra não recarregar a tela... não esquecendo do bootstrap 3 e adminLTE
Para quem é iniciante na área e assitiu o vídeo acima: Node não é framework. Ele é apenas um runtime! React e Jquery também não são frameworks, são bibliotecas!
@@JoseLeandro-gg7gk Blibliotecas e Framework tem um proposito parecido, que é ter um conjunto de ferramentas pré-dispostas a te auxiliar no desenvolvimento. Entretanto uma bliblioteca não dita como deve ser o desenvolvimento ou como você deve organizar seu projeto, ao contrario de frameworks.
E JavaScript é syntactic sugar de C++... O ponto é, se vc entendeu, show de bola kkkkk não é o tipo de informação que é tão importante de se saber no dia a dia de trampo
@@jlucsx Se for seguir a sua lógica, toda linguagem é syntactic sugar de uma outra linguagem, a final de contas para se criar uma você precisa de outra, o que invalida o seu argumento...
@@maykrpc puts, nem era pra chegar nesse ponto, mano... Estava me referindo ao *fato* de JS ser convertido para C++ (no browser e no Node) pra daí seguir o restante do processo até chegar na CPU. Novamente, meu ponto: se vc entendeu o que o cara falou no vídeo, o propósito tá cumprido.
Node não é um framework, é um runtime, e se está com problemas de performance no back pra escalar é porque não sabe usar promises no event loop para tarefas assíncronas. OBS: Sei que performance não está ligado só à isso, mas é uma das.
NodeJS é o ambiente onde o JS vai rodar, Express, Fastify, Nestjs são os frameworks de desenvolvimento que vao gerar códigos que o NodeJS executa, questão de reclamar da tipagem basta usar Typescript, pessoas que entendem o mínimo de desenvolvimento dessa stack sabe que js puro no desenvolvimento nao é seguro e nem cogitado por questão de erros tolos feitos pelo Dev, TS te preserva desses erros sem falar no autocomplite dele que é ótimo, para APIs e aplicações onde vc vai ter bastante I/O qualquer framework que usa node vai atender bem, vc só começa a pensar em trocar essa stack se vc vai lidar com processamento pesado de arquivos, leitura e escrita, onde vai exigir bastante CPU, ainda assim a formas relativamente simples de escalar no NodeJS, basta entender da tech que vai saber o que fazer, utilizo Nodejs para a maioria das minhas soluções e acho muito mais rápido o desenvolvimento, simples e entendivel para demais devs do que usar Java por exemplo (Nao estou falando que é melhor, apenas a minha dev-experience), outra coisa que pessoal esquece é que JS e NodeJS evoluiram e nao são as mesmas techs de 2010-2012, NodeJS na versão 12+ praticamente é outro runtime, deviam deixar seus preconceitos e deixarem de ser fanboys de linguagens/frameworks e aceitarem que ferramentas evoluem e podem sim se equiparar e resolver problemas tão bem quanto outras consagradas.
O problema do JS ser ruim no backend, tem mais a ver com o NodeJS do que o JS em si. Mas esse problema está relacionado com a forma com Node lida com eventos, que na vdd não é um problema, mas sim é diferente. Muitas pessoas usam o NodeJS sem entender non-blocking, achando q é só pegar uma requisição, tratar e responder, e acabam tendo problemas com o single thread do NodeJS. E muitos também não sabem como fazer o multithreading no Node, entrando no problema do alto uso do CPU com o Node. O ponto é que existe linguagens melhores sim q JS pr lidar com o backend, principalmente quando o assunto é o alto uso do CPU, isso não é nem discussão. Mas tbm é necessário entender o NodeJS bem pr tirar um perfomance bom, oq mt gente ignora, aí a aplicação cresce sem ter como escalar
@@iridium-x7i Java foi feito pra hardware embarcado, não servidores; Python foi feito como linguagem de script prum OS que nem existe mais, não servidores. A gente pode ficar a noite toda nisso aqui.
@@BernardoCodingdev nem leu oq eu escrevi. e falar de framework não muda nada aqui, tô falando de Node em si. tanto o express como o nestjs usam a api HTTP do Node. trabalham da msm forma por debaixo doa panos. eu comentei sobre como o Node lida com eventos, não sobre a abstração fornecida por uma biblioteca
Discordo completamente de falar que JavaScript no backend é "ruim" de performance. Ainda mais com as aprimorações de performance que a V8 e o runtime como um todo vem tomando desde a versão LTS 12 do Node.js. E de que escala estamos falando? Eu pessoalmente já peguei cenários de high throughput com 30k rpm, até 80k rpm em cenários de pico e a nossa aplicação em Nest.js com Fastify aguentou super bem e passou liso no ambiente. E sim: se colocássemos um Golang da vida, nosso custo de infra seria essencialmente bem próximo... Infra com EKS com alguns microserviços rodando em Node.js. E sim: Desse exemplo que citei o cenário é majoritariamente I/O. Era uma infraestrutura de pagamento (gateway de pagamento). Ou seja: se o seu cenário é I/O qualquer stack moderna vai lidar, majoritariamente, super bem hoje em dia. Do Elixir, Go, JVM com Java ao Node.js. Salvo exceções cujo gargalo é alta distribuição com cenários surreais de carga (nesse caso, possivelmente BEAM do Erlang com Elixir vai ser o melhor cenário) Falar que é "ruim" de performance sem explicitar o que exatamente é coisa de bench tosco que não reflete a realidade em PRD. Agora, se estivermos falando algo voltando para CPU Bound: o Node.js tem worker threads hoje no runtime e de fato Go, Rust e etc vão escalar melhor, ponto. Mas ainda assim, tem que ver bem se não faz sentido só ir de Node.js com Worker Threads e approachs do gênero. O ponto é: dúvido muito que o cenário da imensa maioria seja esse: CPU Bound com muita alta carga na maioria dos serviços e endpoints + high throughput..
Concordo MUITO! No meu trabalho, estamos fazendo uma aplicação com Nest e o ORM Prisma, aplicando conceitos de Solid, DDD e Arquitertura Limpa, e até agora, 0 problemas.
Dúvida : vc está descrevendo um cenário de lightweight threads vs worker threads ? Ta dizendo que a performance com várias instâncias de nodejs se equipara a uma linguagem concorrente como Go na maioria dos cenários ? Ou está comparando dois casos que utilizam uma só cpu ? Não entendi bem, pois um programa concorrente vai naturalmente performar mais que uma instância node pela possibilidade de paralelismo. Se puder explicar, seria legal !
@@gustavoforcode8590 excelente ponto man! :) Quero dizer que um modelo com um worker pool dedicado usando workers threads para cenários de CPU-intensive já vai resolver bem para a maioria dos cenários. De fato, o modelo de fibers & continuations, green threads com goroutines ou processos no Erlang/Elixir é superior. Tanto como modelo, como visando performance em sistemas distribuídos para cenários de. I/O e CPU intensive. Por worker threads você pode pensar no mundo Java com Spring WebFlux que usa o modelo de eventos como concorrência e também tem Event Loops via Netty. Também vai escalar bem via pooll dedicado de threads para tarefas intensivas de CPU. Não é a melhor forma, mas no geral, o grosso das aplicações são I/O bound like ou data-intensive. Então, saber lidar com streams e I/O bound vai tender a guiar as regras de negócios. Então, respondendo: no node vai ser mais difícil ter paralelismo real pelo event loop ser core para o modelo, mas o cenário aqui é comparativo de concorrência estrito senso. E em ambos runtimes você consegue resolver super bem. Resolver com Go ou não, é mais pela comodidade e pela dev experience de lidar com um modelo de concorrência melhor. E aí é que tá o cerne da questão: com base nisso, dá para dizer que o Node.js é "ruim" de performance? Nem de longe. Discordo completamente.
@@yuri4dev Entendo, pois trabalho diretamente com isso. Tenho que saber como introduzir conhecimento pela internet. Então me diga meu amigo, essa curiosidade introduzida em você através do meu comentário. Você gostou?
Tempo de desenvolvimento também é algo a ser levado em conta, o tempo para desenvolvimento de um back em node é ridiculamente mais rapido que em java, e isso deve ser levado em conta.
É um ponto a se levar em consideração mesmo, mas quanto mais rápido um sistema fica pronto, mais rápido o patrão pode se livrar do dev; Também tem essa problemática. kk
Eu passei anos na faculdade só no Java e comecei a estudar JS por causa da Rocketseat justamente pela praticidade de fazer Back e Front na mesma linguagem.
Escalar times para uma linguagem é sempre uma dor de cabeça, passei por isso quando fui montar um time voltado para kotlin, e olha que se o ser humaninho sabe java ele joga bem no kotlin. Esse livro é muito bom!
@@kxven5254 O jovem queria ter esse poder eu faço recrutamento quando a empresa pede e os candidatos chegam filtrados para mim, enquanto isso eu tento fazer o que o Augusto Faz com maestria, que é espalhar conhecimento.
Dá pra ir com outra linguagem de forma evolutiva também. Trazendo a complexidade aos poucos quando for necessário. Isso pode sair mais barato que dar um throw no projeto em JS e começar outro no futuro (algo que provavelmente nunca acontecerá devido ao custo e tempo)
A real é que performance da linguagem em si por ex(nodejs) em grande partes dos casos(api rest) não é um dos maiores gargalos quando se faz um app pra web, ja que da pra escalar com containers e etc. Comparando com outras linguagens JIT NodeJS tem uma performance razoável , Typescript sendo confortável e ergonômico e tendo bibliotecas pra grande parte dos problemas acho que é um bom motivo pra usar. Acho uma das melhores pra backend se for fazer REST API grande parte dos casos a não ser que tenha um uso muito especifico e que necessite MUITO de performance, que nem o caso do Discord que trocou de Go pra Rust.
Eu Tb. Trabalho com laminas ( antigo zend framework ). Não gosto de trabalhar com Java script em backend, mas isso é coisa meio pessoal. Sou da época do php 3 ainda, na época javascript era usado só pra mudar ícone quando clicado 😂
Bagunça até Java com Spring pode ser, só depende dos devs. Tô finalizando agora a migração de um monólito Java 8 macarrônico em 9 microsservicos Node. Quebramos o domínio em subdomínios (DDD) e o negócio ficou incrível, 94% de cobertura de testes, APIs respondendo entre 30 e 90ms, comunicação assíncrona com Kafka
Kkkkkk bagunça? Você sabe o que e DDD, clean arch clean Code se vc não sabe ou ROOTs isso pode ser aplicado em qualquer linguagem, retificando usa -se o javascript turbinado Typescript pra isso ou retardado vai pesquisar antes de falar merd@
Eu nao entendo por que o node seria um problema no cenario de milhoes de users (a ponto de precisar refazer o backend nesse cenario), tipo nao seria o caso colocar o servico em um pod e escalar horizontalmente conforme aumentasse a demanda? O fluxo é diferente em outras linguagens?
Esse processo de escalonamento é o mesmo para a maioria das linguagens, se a pessoa for muito pragmática ela vai empurrar um Go pra equipe, mais que isso a pessoa provavelmente está delirando e precisa ler o livro "Solving Imaginary Scaling Issues".
As grandes empresas acabam re-escrevendo. Dificilmente vc vê "hotspots" de software de altíssima escalabilidade (google, github, amazon) escritos em node.js. Não é que "precisa" refazer, precisar não necessariamente precisa. Mas com algo mais performático vc consegue economizar ciclos de CPU, ou seja, custos. E esses custos pra big techs são na casa dos milhões. Então sim, se se a v1 da sua empresa é em Node, e a empresa cresceu pra ser do tamanho do Google, as partes em Node vão uma por uma sendo reescritas. Mas, na maioria das empresas, realmente nunca vai precisar mesmo.
Provavelmente ainda vai continuar usando node em muita coisa, mas na medida que escala o system design vai ficando complexo, e para cada implementação existe uma tecnologia melhor para cada pedaço do sistema. Tipo, caso surja necessidade de relatórios avançados que antes eram feitos de forma simplória no node você vai querer optar por alguma stack em python, pra lidar com filas talvez prefira usar go ou rust e assim vai...
Uma pequena correção, nodejs não é um framework, é um runtime (tempo de execução) que permite o javascript rodar fora do browser (navegador). Se minha colocação estiver errada comente aqui em baixo e me corrija, por favor.
As desvantagens nós já sabemos, o sort de JavaScript é completamente confuso, várias coisas em JavaScript são completamente confusas e não intuitivas (), mas toda linguagem vai ter algo não intuitivo: Python com for else, que é completamente não intuitivo e mal desenhado, Golang sem try/catch, etc...
Pessoal do comentário que está falando que o JS não serve para aplicações server side, não sabe o que está falando e não conhece o framework Nestjs... rsrsrs aiai
Confesso que prefiro o type system do typescript ao invés do golang kkkk. Usar rust pra back-end seria um sonho mas realmente é bem raro e menos produtivo.
@@dev.antunes typescript é um superset, n é verdadeiramente tipado, os tipos em ts nao influencia na memoria, e vai deixar seu backend mais lento pq vai ter que compilar pra js.
@@dev.antunes no fim quem faz o gerenciamento da memoria é so o garbage collector, e ele por si so faz o feijao com arroz, pra tu ter um backend mais robusto e performatico e verdadeiramente tipado teria que pegar outra coisa fortemente tipada, vc acha que go é tao popular e tao performatico atoa? :/
Qual é a sua fonte de pesquisa dos frameworks mais populares? Eu não sei o pessoal, mas eu sempre fico achando que essas listas de linguagens de programação ou frameworks mais utilizados são sempre enviesadas hehe
Uma indicação: Goodbye javascript (for now) ua-cam.com/video/gNDBwxeBrF4/v-deo.htmlsi=PPgUVXqAJVwLLIwX (Developing in the JavaScript/TypeScript ecosystem is too complex and creates many external dependencies. I'm looking forward to the videos about Go language and HTMX.)
Não é bom. Imagine que o nodejs já não é tão bom para esse cenário como dito no vídeo, e ainda você coloca um framework por cima. Outra questão é que o nestjs usa por trás dos panos o express que é fraco nesse quesito, então você tem o nodejs -> express -> nestjs. Eu já vi que dá para melhorar o nestjs trocando o express por outras bibliotecas como o fastify e trocar também a forma como ele serializa o json... mas creio que para o nestjs ser algo razoável para cenário de alta escalabilidade seja mesmo trocar o runtime de nodejs para o bun ou o winterjs.
irmão, você não está pegando ajudante não? tô precisando de umas experiências técnicas na área, sem remuneração somente ajudar e ganhar experiência em javaScript na prática
Numa aplicação web seu banco será um gargalo muito antes do Node. Esse pessoal se baseia em benchmark sintético, normalmente sem um banco na jogada. Pega os habkings das rinhas de backend.
O JS é uma linguagem bem bacana simples de fazer as coisas e tal, mas eu só gosto dela para aplicações que possuem uma regra de negócio bem slim ou para criação de apis mais enxutas, para coisas com domínios mais complexos eu com certeza optaria por linguagens mais parrudas como Java, Go e etc. Claro que como o Augusto falou, a gente leva várias coisas em consideração pra escolher uma stack para se trabalhar em projetos, enfim.
concordo plenamente com vc, js fora da web é pra quebrar galho em aplicaçoes mais simples, a glr fica put quando falo que node n é tudo isso e so serve pra quebrar o galho ou que nativo sempre sera superior a hibrido no mobile kkkk, acham que as ferramentas que usam sao bala de prata e que resolvem tudo, pode ate resolver, mas nao vai ser com eficiencia.
Cara, estou vendo javascript, angular, vou comecar o typescript e quero tbm estudar GO. Acha que é uma boa isar GO pra banck-end e javascript pra front, e sobre o Typrscript eu ainda não comecei a estudar, então nao sei muito além de adicionar tipagem estática no javascript. Acha uma boa estudar essas coisas com visão no mercado de trabalho?
Escolhe 1 só e fica bom nela, recomendo que seja Go, acho mais fácil que javascript e ta menos saturado de profissionais. A linguagem que falei é uma opinião minha, sinta-se livre pra escolher, mas ficar tentando aprender todas a linguagens do mundo não vai ter levar tão longe.
primeiro foque so em um manin, dps de mt tempo ja com experiencia com a ferramente que escolheu ai sim vc procura outra coisa pra estudar quando se fala de linguagem. pq o problema n é estudar so a linguagem... o problema é quando vc precisa estudar todo o resto que envolve desenvolvimento de sistemas e trabalho agil em times kkkk
Fal Augusto, tenho 15 anos e m insteresseu muito por esse mercado da programação de uns tempos pra cá, porém não consigo gostar de desenvolvimento web, não é a area que quero atuar. Eu realmente quero aprender a desenvolver graficamente sem utilizar coisas prontas e ferramentas como JS para criar interfaces gráficas. Isso me faz quase que obrigatoriamente estudar OpenGL, Vulkan ou ate mesmo DrirectX(optei por OpenGL). Mas no quisito de mercado, é relativamente difícil encontrar alguma vaga qu eu utilize isso, o que me leva ao pensamento de porque esse mercado é pequeno e praticamente todas as vagas são para web? Compensa mesmo aprender isso ou vale a pena se render a apenas desenvolver sites?
@@RaikiriEdits Academia quer dizer ir pra universidade e fazer pesquisa científica em computação gráfica. Criar e desenvolver novos algoritmos, escrever artigos científicos, esse tipo de coisa
Augustão, não sei quais seus planos p/ o canal, mas cria uma aba de membros. Não sei qual o repasse do youtube p/ essa feat, mas seria massa! Ficaria feliz em ajudar, seu conteúdo é sempre mt massa.
Muito bom esse vídeo sobre vantagens em se utilizar JavaScript no backend, alguns pontos que eu anotei:
- Fácil contratação, a maioria dos desenvolvedores sabem JavaScript, é uma linguagem amplamente difundida
- Curva de aprendizado pequena, a empresa precisa treinar os desenvolvedores rápido, e JavaScript é uma linguagem simples, isso ajuda no onboarding ágil
- Quase com certeza o frontend dos projetos serão em JavaScript, então os devs frontend também poderão ajudar no backend caso necessário
As desvantagens nós já sabemos, o sort de JavaScript é completamente confuso, várias coisas em JavaScript são completamente confusas e não intuitivas (), mas JavaScript não é o único, todas as linguagens vão ter algo não intuitivo: Python com for else, que é completamente não intuitivo e mal desenhado, o tratamento de erros no Golang sem try/catch, a gestão de memória no C++, etc...
Conteúdo muito bom mano!
Galera esquece que em tecnologia não existe bala de prata, pra toda escolha tem os prós e os contras.
Venho de um background de JS, e usar Go está sendo muito bom, tem um ecossistema completinho e a experiência de desenvolver é muito positiva!
Resolvendo problemas imaginários de escala
Kkkkkkkkkk
js?
backend é php, de preferencia tudo junto com o front num mesmo arquivo .php, acessa o banco e logo em baixo bota o dado no html e vala, go horse na veia.
Já trabalhei em um projeto assim, péssimo para manter, péssimo para dar manutenção
😂😂😂😂😂😂😂😂
sai fora cara, ta falando besteira. O negócio é usar CakePHP com frontend Jquery. Toda view tem que ser mantida com JQuery e a troca de dados só com ajax que é pra não recarregar a tela... não esquecendo do bootstrap 3 e adminLTE
@@raphael-azambuja 😂
@@raphael-azambuja kkkk
Para quem é iniciante na área e assitiu o vídeo acima: Node não é framework. Ele é apenas um runtime! React e Jquery também não são frameworks, são bibliotecas!
sou iniciante, qual a diferença entre frameworks e Bibliotecas, desculpa a ignorancia
Sinto dizer mas React é sim um framework, agora quanto ao JQuery eu concordo que é apenas uma biblioteca.
@@JoseLeandro-gg7gk Blibliotecas e Framework tem um proposito parecido, que é ter um conjunto de ferramentas pré-dispostas a te auxiliar no desenvolvimento. Entretanto uma bliblioteca não dita como deve ser o desenvolvimento ou como você deve organizar seu projeto, ao contrario de frameworks.
@@hadawardgz 5 anos de react profissionalmete e não, react não é um framework!
@@hadawardgz então a documentação do react ta errado xd
Node js não é um framework é um runtime....Express, Nest e next são frameworks
E JavaScript é syntactic sugar de C++... O ponto é, se vc entendeu, show de bola kkkkk não é o tipo de informação que é tão importante de se saber no dia a dia de trampo
@@jlucsx esse foi o comentario mais idiota que já li na minha vida, obrigado!
@@jlucsx Se for seguir a sua lógica, toda linguagem é syntactic sugar de uma outra linguagem, a final de contas para se criar uma você precisa de outra, o que invalida o seu argumento...
@@maykrpc puts, nem era pra chegar nesse ponto, mano... Estava me referindo ao *fato* de JS ser convertido para C++ (no browser e no Node) pra daí seguir o restante do processo até chegar na CPU.
Novamente, meu ponto: se vc entendeu o que o cara falou no vídeo, o propósito tá cumprido.
@@jorgerezende2386@maykrpc Erick Wendel palestrou sobre: ua-cam.com/video/W-hFZC8q_AA/v-deo.html
Node não é um framework, é um runtime, e se está com problemas de performance no back pra escalar é porque não sabe usar promises no event loop para tarefas assíncronas.
OBS: Sei que performance não está ligado só à isso, mas é uma das.
correcto estava pra falar isso
NodeJS é o ambiente onde o JS vai rodar, Express, Fastify, Nestjs são os frameworks de desenvolvimento que vao gerar códigos que o NodeJS executa, questão de reclamar da tipagem basta usar Typescript, pessoas que entendem o mínimo de desenvolvimento dessa stack sabe que js puro no desenvolvimento nao é seguro e nem cogitado por questão de erros tolos feitos pelo Dev, TS te preserva desses erros sem falar no autocomplite dele que é ótimo, para APIs e aplicações onde vc vai ter bastante I/O qualquer framework que usa node vai atender bem, vc só começa a pensar em trocar essa stack se vc vai lidar com processamento pesado de arquivos, leitura e escrita, onde vai exigir bastante CPU, ainda assim a formas relativamente simples de escalar no NodeJS, basta entender da tech que vai saber o que fazer, utilizo Nodejs para a maioria das minhas soluções e acho muito mais rápido o desenvolvimento, simples e entendivel para demais devs do que usar Java por exemplo (Nao estou falando que é melhor, apenas a minha dev-experience), outra coisa que pessoal esquece é que JS e NodeJS evoluiram e nao são as mesmas techs de 2010-2012, NodeJS na versão 12+ praticamente é outro runtime, deviam deixar seus preconceitos e deixarem de ser fanboys de linguagens/frameworks e aceitarem que ferramentas evoluem e podem sim se equiparar e resolver problemas tão bem quanto outras consagradas.
O problema do JS ser ruim no backend, tem mais a ver com o NodeJS do que o JS em si. Mas esse problema está relacionado com a forma com Node lida com eventos, que na vdd não é um problema, mas sim é diferente. Muitas pessoas usam o NodeJS sem entender non-blocking, achando q é só pegar uma requisição, tratar e responder, e acabam tendo problemas com o single thread do NodeJS. E muitos também não sabem como fazer o multithreading no Node, entrando no problema do alto uso do CPU com o Node. O ponto é que existe linguagens melhores sim q JS pr lidar com o backend, principalmente quando o assunto é o alto uso do CPU, isso não é nem discussão. Mas tbm é necessário entender o NodeJS bem pr tirar um perfomance bom, oq mt gente ignora, aí a aplicação cresce sem ter como escalar
Js foi feito para front end não servidores.
@@iridium-x7i Java foi feito pra hardware embarcado, não servidores; Python foi feito como linguagem de script prum OS que nem existe mais, não servidores. A gente pode ficar a noite toda nisso aqui.
js ruim no backend? Dê uma olhada no framework Nest e você irá pensar duas vezes ao falar isso!
@@BernardoCodingdev nem leu oq eu escrevi. e falar de framework não muda nada aqui, tô falando de Node em si. tanto o express como o nestjs usam a api HTTP do Node. trabalham da msm forma por debaixo doa panos. eu comentei sobre como o Node lida com eventos, não sobre a abstração fornecida por uma biblioteca
@@danielsoares1608 exatamente kkkkkk
Discordo completamente de falar que JavaScript no backend é "ruim" de performance.
Ainda mais com as aprimorações de performance que a V8 e o runtime como um todo vem tomando desde a versão LTS 12 do Node.js.
E de que escala estamos falando? Eu pessoalmente já peguei cenários de high throughput com 30k rpm, até 80k rpm em cenários de pico e a nossa aplicação em Nest.js com Fastify aguentou super bem e passou liso no ambiente. E sim: se colocássemos um Golang da vida, nosso custo de infra seria essencialmente bem próximo... Infra com EKS com alguns microserviços rodando em Node.js.
E sim:
Desse exemplo que citei o cenário é majoritariamente I/O. Era uma infraestrutura de pagamento (gateway de pagamento).
Ou seja: se o seu cenário é I/O qualquer stack moderna vai lidar, majoritariamente, super bem hoje em dia. Do Elixir, Go, JVM com Java ao Node.js.
Salvo exceções cujo gargalo é alta distribuição com cenários surreais de carga (nesse caso, possivelmente BEAM do Erlang com Elixir vai ser o melhor cenário)
Falar que é "ruim" de performance sem explicitar o que exatamente é coisa de bench tosco que não reflete a realidade em PRD.
Agora, se estivermos falando algo voltando para CPU Bound: o Node.js tem worker threads hoje no runtime e de fato Go, Rust e etc vão escalar melhor, ponto. Mas ainda assim, tem que ver bem se não faz sentido só ir de Node.js com Worker Threads e approachs do gênero.
O ponto é: dúvido muito que o cenário da imensa maioria seja esse: CPU Bound com muita alta carga na maioria dos serviços e endpoints + high throughput..
irmão, você não está pegando ajudante não? tô precisando de umas experiências técnicas na área, sem remuneração somente ajudar e ganhar experiência.
Concordo MUITO! No meu trabalho, estamos fazendo uma aplicação com Nest e o ORM Prisma, aplicando conceitos de Solid, DDD e Arquitertura Limpa, e até agora, 0 problemas.
JS é ruim em tudo, famosa linguagem gambiarra
Dúvida : vc está descrevendo um cenário de lightweight threads vs worker threads ? Ta dizendo que a performance com várias instâncias de nodejs se equipara a uma linguagem concorrente como Go na maioria dos cenários ? Ou está comparando dois casos que utilizam uma só cpu ? Não entendi bem, pois um programa concorrente vai naturalmente performar mais que uma instância node pela possibilidade de paralelismo. Se puder explicar, seria legal !
@@gustavoforcode8590 excelente ponto man! :)
Quero dizer que um modelo com um worker pool dedicado usando workers threads para cenários de CPU-intensive já vai resolver bem para a maioria dos cenários.
De fato, o modelo de fibers & continuations, green threads com goroutines ou processos no Erlang/Elixir é superior. Tanto como modelo, como visando performance em sistemas distribuídos para cenários de. I/O e CPU intensive.
Por worker threads você pode pensar no mundo Java com Spring WebFlux que usa o modelo de eventos como concorrência e também tem Event Loops via Netty.
Também vai escalar bem via pooll dedicado de threads para tarefas intensivas de CPU.
Não é a melhor forma, mas no geral, o grosso das aplicações são I/O bound like ou data-intensive.
Então, saber lidar com streams e I/O bound vai tender a guiar as regras de negócios.
Então, respondendo: no node vai ser mais difícil ter paralelismo real pelo event loop ser core para o modelo, mas o cenário aqui é comparativo de concorrência estrito senso.
E em ambos runtimes você consegue resolver super bem. Resolver com Go ou não, é mais pela comodidade e pela dev experience de lidar com um modelo de concorrência melhor.
E aí é que tá o cerne da questão: com base nisso, dá para dizer que o Node.js é "ruim" de performance?
Nem de longe. Discordo completamente.
Aulas!!!! Erra nunca.
Na Alertpix usamos fastify + next :) full js
Traindo nosso Python
😢
*C* sabe que Python, Javascript e muitas outras usam a mesma coisa por trás né?
@@seoky6 então vc entende de coisas que são introduzidas por trás?
@@yuri4dev Entendo, pois trabalho diretamente com isso. Tenho que saber como introduzir conhecimento pela internet. Então me diga meu amigo, essa curiosidade introduzida em você através do meu comentário. Você gostou?
@@yuri4devtonto
node.js não seria mais um runtime do que um framework? No caso o express seria um framework, não?
node.js é só um ambiente, ele falou mrd kkkk
express ta mais pra micro-framework
Node é lindo! Resolvendo todos os meus problemas.
Tempo de desenvolvimento também é algo a ser levado em conta, o tempo para desenvolvimento de um back em node é ridiculamente mais rapido que em java, e isso deve ser levado em conta.
É um ponto a se levar em consideração mesmo, mas quanto mais rápido um sistema fica pronto, mais rápido o patrão pode se livrar do dev; Também tem essa problemática. kk
Eu passei anos na faculdade só no Java e comecei a estudar JS por causa da Rocketseat justamente pela praticidade de fazer Back e Front na mesma linguagem.
Escalar times para uma linguagem é sempre uma dor de cabeça, passei por isso quando fui montar um time voltado para kotlin, e olha que se o ser humaninho sabe java ele joga bem no kotlin. Esse livro é muito bom!
Bom saber.
Me chama pra tua equipe para eu poder começar na área? só quero experiência, sem remuneração apenas ajudar e aprender.
@@kxven5254 O jovem queria ter esse poder eu faço recrutamento quando a empresa pede e os candidatos chegam filtrados para mim, enquanto isso eu tento fazer o que o Augusto Faz com maestria, que é espalhar conhecimento.
@@TheDigitalBrickLayer Eu estou precisando desse conhecimento mano, me passa seu discord para a gente poder conversar qualquer hora?
Dá pra ir com outra linguagem de forma evolutiva também. Trazendo a complexidade aos poucos quando for necessário. Isso pode sair mais barato que dar um throw no projeto em JS e começar outro no futuro (algo que provavelmente nunca acontecerá devido ao custo e tempo)
Eu comprei esse livro há um tempo, muito bom!
A real é que performance da linguagem em si por ex(nodejs) em grande partes dos casos(api rest) não é um dos maiores gargalos quando se faz um app pra web, ja que da pra escalar com containers e etc. Comparando com outras linguagens JIT NodeJS tem uma performance razoável , Typescript sendo confortável e ergonômico e tendo bibliotecas pra grande parte dos problemas acho que é um bom motivo pra usar. Acho uma das melhores pra backend se for fazer REST API grande parte dos casos a não ser que tenha um uso muito especifico e que necessite MUITO de performance, que nem o caso do Discord que trocou de Go pra Rust.
ótima análise amigo
js
sim, no sentido de negócios faz sentido, apesar de falar isso me faz contorcer por dentro kkkk
Video TOP. Faz um video analisando o django sob a mesma ótica?
@@rafael_tg boa!
Trabalho com Js no front com Vue e PHP com laravel no back, acho que eu nao gostaria de um sistema grande com back em js, deve ser uma bagunça
Eu Tb. Trabalho com laminas ( antigo zend framework ).
Não gosto de trabalhar com Java script em backend, mas isso é coisa meio pessoal. Sou da época do php 3 ainda, na época javascript era usado só pra mudar ícone quando clicado 😂
Bagunça até Java com Spring pode ser, só depende dos devs. Tô finalizando agora a migração de um monólito Java 8 macarrônico em 9 microsservicos Node. Quebramos o domínio em subdomínios (DDD) e o negócio ficou incrível, 94% de cobertura de testes, APIs respondendo entre 30 e 90ms, comunicação assíncrona com Kafka
@@danielsoares1608 boa! Usou jest e Cypress?
Kkkkkk bagunça? Você sabe o que e DDD, clean arch clean Code se vc não sabe ou ROOTs isso pode ser aplicado em qualquer linguagem, retificando usa -se o javascript turbinado Typescript pra isso ou retardado vai pesquisar antes de falar merd@
Node é um runtime, não?
Eu nao entendo por que o node seria um problema no cenario de milhoes de users (a ponto de precisar refazer o backend nesse cenario), tipo nao seria o caso colocar o servico em um pod e escalar horizontalmente conforme aumentasse a demanda? O fluxo é diferente em outras linguagens?
Esse processo de escalonamento é o mesmo para a maioria das linguagens, se a pessoa for muito pragmática ela vai empurrar um Go pra equipe, mais que isso a pessoa provavelmente está delirando e precisa ler o livro "Solving Imaginary Scaling Issues".
As grandes empresas acabam re-escrevendo. Dificilmente vc vê "hotspots" de software de altíssima escalabilidade (google, github, amazon) escritos em node.js. Não é que "precisa" refazer, precisar não necessariamente precisa. Mas com algo mais performático vc consegue economizar ciclos de CPU, ou seja, custos. E esses custos pra big techs são na casa dos milhões. Então sim, se se a v1 da sua empresa é em Node, e a empresa cresceu pra ser do tamanho do Google, as partes em Node vão uma por uma sendo reescritas.
Mas, na maioria das empresas, realmente nunca vai precisar mesmo.
Provavelmente ainda vai continuar usando node em muita coisa, mas na medida que escala o system design vai ficando complexo, e para cada implementação existe uma tecnologia melhor para cada pedaço do sistema. Tipo, caso surja necessidade de relatórios avançados que antes eram feitos de forma simplória no node você vai querer optar por alguma stack em python, pra lidar com filas talvez prefira usar go ou rust e assim vai...
Uma pequena correção, nodejs não é um framework, é um runtime (tempo de execução) que permite o javascript rodar fora do browser (navegador).
Se minha colocação estiver errada comente aqui em baixo e me corrija, por favor.
O melhor que existe é o PHP, não existe nada melhor que aquilo
ninguém conhece PHP
As desvantagens nós já sabemos, o sort de JavaScript é completamente confuso, várias coisas em JavaScript são completamente confusas e não intuitivas (), mas toda linguagem vai ter algo não intuitivo: Python com for else, que é completamente não intuitivo e mal desenhado, Golang sem try/catch, etc...
o tratamento de erros no Golang, sem try/catch...
Pessoal do comentário que está falando que o JS não serve para aplicações server side, não sabe o que está falando e não conhece o framework Nestjs... rsrsrs aiai
Confesso que prefiro o type system do typescript ao invés do golang kkkk. Usar rust pra back-end seria um sonho mas realmente é bem raro e menos produtivo.
qual linguagem consegue ter a integração back+front q o js tem com o next?
laravel talvez ?
@@str2254 nao roda php no front
várias linguagens se for usar o webassembly, mas nn vale a pena pq nn terá suporte da comunidade
Acho ruim usar JS no backend porque ele não é estaticamente tipado.
TypeScript?
@@dev.antunes tb n
@@dev.antunes typescript é um superset, n é verdadeiramente tipado, os tipos em ts nao influencia na memoria, e vai deixar seu backend mais lento pq vai ter que compilar pra js.
@@dev.antunes no fim quem faz o gerenciamento da memoria é so o garbage collector, e ele por si so faz o feijao com arroz, pra tu ter um backend mais robusto e performatico e verdadeiramente tipado teria que pegar outra coisa fortemente tipada, vc acha que go é tao popular e tao performatico atoa? :/
Cria uma aba de membros com valod acessível e solta videos de projetos backend
Qual é a sua fonte de pesquisa dos frameworks mais populares? Eu não sei o pessoal, mas eu sempre fico achando que essas listas de linguagens de programação ou frameworks mais utilizados são sempre enviesadas hehe
@@emanoelvianna é a do stackoverflow, acontece todo ano
Sempre vejo uns vídeos desse brother interessante, mas falar que Node.js é FRAMEWORK quebrou o vídeo kkk
php still here
NestJs no Back e NextJs no Front? 🤔
Good shit as always
Uma indicação: Goodbye javascript (for now) ua-cam.com/video/gNDBwxeBrF4/v-deo.htmlsi=PPgUVXqAJVwLLIwX (Developing in the JavaScript/TypeScript ecosystem is too complex and creates many external dependencies. I'm looking forward to the videos about Go language and HTMX.)
Parabéns pelo conteúdo! Qual o modelo desse mic ?
É um DJI MIC 2. Aqui (Europa) não é tão caro, mas no Brasil acaba sendo um pouco proibitivo o preço, R$3.150 agora amzn.to/3ycB8iG
E o NestJS é tão ruim assim em escalabilidade nesse cenário de milhões? uso ele e acho uma maravilha, resolvendo todos meus problemas no backend
Não é bom. Imagine que o nodejs já não é tão bom para esse cenário como dito no vídeo, e ainda você coloca um framework por cima. Outra questão é que o nestjs usa por trás dos panos o express que é fraco nesse quesito, então você tem o nodejs -> express -> nestjs. Eu já vi que dá para melhorar o nestjs trocando o express por outras bibliotecas como o fastify e trocar também a forma como ele serializa o json... mas creio que para o nestjs ser algo razoável para cenário de alta escalabilidade seja mesmo trocar o runtime de nodejs para o bun ou o winterjs.
irmão, você não está pegando ajudante não? tô precisando de umas experiências técnicas na área, sem remuneração somente ajudar e ganhar experiência em javaScript na prática
Numa aplicação web seu banco será um gargalo muito antes do Node. Esse pessoal se baseia em benchmark sintético, normalmente sem um banco na jogada. Pega os habkings das rinhas de backend.
Resumindo js no back == gambiarra, porem com a demanda de devs full stacks ela vira uma exelente escolha olhando pelo lado de negócios da empresa.
backend para mim sempre foi Java , C# , hj o pessoal quer fazer tudo am javascript
caralho dog ce ta muito calvo 😮
será uma consequência de ser senior?
node é framework?
Não, é um runtime que permite js rodar fora do browser
Parei quando ele disse que NodeJs é um framework
Será que foi pra gerar um pouco de engajamento?
O JS é uma linguagem bem bacana simples de fazer as coisas e tal, mas eu só gosto dela para aplicações que possuem uma regra de negócio bem slim ou para criação de apis mais enxutas, para coisas com domínios mais complexos eu com certeza optaria por linguagens mais parrudas como Java, Go e etc. Claro que como o Augusto falou, a gente leva várias coisas em consideração pra escolher uma stack para se trabalhar em projetos, enfim.
irmão, você não está pegando ajudante não? tô precisando de umas experiências técnicas na área, sem remuneração somente ajudar e ganhar experiência
concordo plenamente com vc, js fora da web é pra quebrar galho em aplicaçoes mais simples, a glr fica put quando falo que node n é tudo isso e so serve pra quebrar o galho ou que nativo sempre sera superior a hibrido no mobile kkkk, acham que as ferramentas que usam sao bala de prata e que resolvem tudo, pode ate resolver, mas nao vai ser com eficiencia.
Pagando eu chamo até de amor
Irmão só esta faltando um server seu no discord, pra gente trocar um papo produtivo de dev
irmão, você não está pegando ajudante não? tô precisando de umas experiências técnicas na área, sem remuneração somente ajudar e ganhar experiência
quanto tempo demora pra amazon enviar? uma vez espere mais de mes e acabei cancelando.
Cara, estou vendo javascript, angular, vou comecar o typescript e quero tbm estudar GO. Acha que é uma boa isar GO pra banck-end e javascript pra front, e sobre o Typrscript eu ainda não comecei a estudar, então nao sei muito além de adicionar tipagem estática no javascript. Acha uma boa estudar essas coisas com visão no mercado de trabalho?
Escolhe 1 só e fica bom nela, recomendo que seja Go, acho mais fácil que javascript e ta menos saturado de profissionais. A linguagem que falei é uma opinião minha, sinta-se livre pra escolher, mas ficar tentando aprender todas a linguagens do mundo não vai ter levar tão longe.
primeiro foque so em um manin, dps de mt tempo ja com experiencia com a ferramente que escolheu ai sim vc procura outra coisa pra estudar quando se fala de linguagem. pq o problema n é estudar so a linguagem... o problema é quando vc precisa estudar todo o resto que envolve desenvolvimento de sistemas e trabalho agil em times kkkk
Fal Augusto, tenho 15 anos e m insteresseu muito por esse mercado da programação de uns tempos pra cá, porém não consigo gostar de desenvolvimento web, não é a area que quero atuar. Eu realmente quero aprender a desenvolver graficamente sem utilizar coisas prontas e ferramentas como JS para criar interfaces gráficas. Isso me faz quase que obrigatoriamente estudar OpenGL, Vulkan ou ate mesmo DrirectX(optei por OpenGL). Mas no quisito de mercado, é relativamente difícil encontrar alguma vaga qu eu utilize isso, o que me leva ao pensamento de porque esse mercado é pequeno e praticamente todas as vagas são para web? Compensa mesmo aprender isso ou vale a pena se render a apenas desenvolver sites?
Vc pode trabalhar pra fora ou ir pra academia. Talvez se interesse por visão computacional também
@@str2254 eu não entendi a parte da academia, mas pesquisarei sobre visão computacional.
@@str2254 não. Não sei se esta difícil de entender o que escrevi mas é uma área bastante diferente da que quero seguir.
@@RaikiriEdits Academia quer dizer ir pra universidade e fazer pesquisa científica em computação gráfica. Criar e desenvolver novos algoritmos, escrever artigos científicos, esse tipo de coisa
Nestjs typescript no backend e Javascript React no front vou tentar jsx no React no front end
Tenho a impressão que já sonhei com você.
O tanto de dev coda fofo aqui discutindo se nodejs é runtime ou framework hahahah, vão codar e parem de falar as neras.
O problema do JavaScript no backend é a falta de tipagem estática no runtime. É muito fácil criar software cheio de problemas com JavaScript.
pois é, aí vem um bobão e fala "a mas tem typescript pra tipagem", mostrando que não entende nem as ferramentas que trabalha.
É tão ruim que é bom (e paga todos os meus boletos)
Drogas? Tô fora! Pego minha bike e vou embora!
n quero saber se e lento cara, eu to onde ta o dinheiro.