Nossa startup com NextJS+Supabase+Tailwind fomos do MVP pra 150 clientes B2B (com mais de 1 milhões de API calls por semana) em 10 meses. Tudo isso em 3 devs
@@Wesley9xd estamos no plano pro de $25 mensal pra ter backups diários, etc. Mas estamos indo pro plano enterprise que o mínimo é uns 1mil dolares mensais. Aí tu já consegue alguns recursos como suporte 24/7 dedicado, point in time recovery do banco, replicas, etc
@@Wesley9xd bem generoso sim. Ficamos no free plan por um bom tempo. Errei em usar o storage deles e logo ultrassei o 1gb do free plan. Depois migramos as imagens direto pra AWS S3 e nem precisava mais do plano pago. Mas com eu disse anteriormente, o plano pago tem backups diários e um pouco mais de prioridade no suporte. Eu gosto muito.
Estou atualmente fazendo um projeto pessoal justamente usando esse recurso do Next.js, codando o back-end junto ao front , usando prisma e o planetscale como banco de dados e realizar o deploy na Vercel. Realmente é uma ferramenta muito completa.
@@LucasHenrique-xm8xc Containeriza com o docker e sobe em cloud de sua escolha. AWS te um free tier que dá pra fazer uns testes e usando o docker-machine o processo de deploy é ainda mas simplificado. Dá uma olhada no canal da Rocket que tem um vídeo sobre isso.
Que vídeo sensacional. Pra mim que não sou formado na área, tampouco acompanhei a evolução do desenvolvimento web por tanto tempo quanto você, é muito interessante ter acesso a esse tipo de conteúdo. Pq as vezes não faz muito sentido pra mim esse tipo de discussão. Agora faz. Muito bom mesmo.
Diegão serverless é bom demais mesmo. A vercel tem suporte pra Python, Ruby, Node e Go. Já fiz alguns CRUD no MongoDB (atlas) usando Python ano passado e subi na vercel tranquilamente, nessa ideia em 19:17.
É incrível o quanto o conteúdo da Rocketseat evoluiu ao longo dos anos. Já fazia algum tempo que eu não consumia os vídeos aqui do canal e voltando agora eu tô impressionado com a qualidade do que tá sendo produzido 👌👏👏
Bom analisando talvez no futuro só vale a pena quando vc sabe que seu backend irá servir várias aplicações diferentes. fora isso é melhor fazer tudo junto mesmo
Hoje Docker facilita muito o deploy, tanto para back quanto para front, acredito que sua fala para desenvolvedores fullstack se encaixa quando se fala neste ambiente em especifico (js/ ts).
De fato quando trabalhamos com front e back se torna melhor ter os códigos próximos, eu mesmo utilizo muito os workspaces do VS Code para alternar melhor. Um ponto interessante dessa junção é quando temos comportamentos no front que dependem de dados do back, como tipos de inputs, cores, animações e tamanhos. Se ambos estiverem no mesmo local o tempo de resposta é quase instantâneo de ocorrer, ao invés de tentar encontrar um servidor mais próximo e só então fazer a requisição. Estou utilizando em um novo projeto e sem dúvidas funciona melhor, ainda mais tendo que utilizar MetaMask e outras carteiras direto do browser para autenticar usuários.
O bom é que não é obrigatório, isso só vai trazer mais vantagem pro lado do Next, por que ainda vai dar pra renderizar components client-side normalmente usando a diretiva 'use client', sem falar que alguns hooks só vão funcionar dessa forma pois não é possível usá-los com server components
Desde o primeiro dia que conheci o Next.js eu pensei em algo voltado nesse sentido, porém é claro que isso veio maturando com as atualizações do Next.js e acho que vale muito conteúdo voltado pra isso. Parabéns Diegão!
Para um projeto que tenha a certeza que vai rodar somente web esse é o melhor dos mundos. Porém pensando em escalabilidade para mobile e consumo de terceiros melhor desacoplar através de uma api ainda é o melhor caminho.
Faaaaala Dev, blzzzz? Show demais Diegao, to fznd um projeto usando nextjs pro front e nest pro back e o legal de ver isso é saber que futuramente posso utilizar somente um framework para todo o processo e vcs da rockseat tem me ajudado muito na evolucao e aprendizado dessas ferramentas e dos conceitos por traz de cada uma. (deixa o tema do seu vscode na descricao, pq eu sou fominha de tema e troco todo dia hahahaha)
Diego sempre com vscode mais lindo, melhores temas haha. Excelente explicação, tenho acompanhado as evoluções do next e o direcionamento que o desenvolvimento web está tomando e fico bastante empolgado. Por mais que o pessoal do PHP esteja zoando esse circulo que o javascript fez de client side de volta pra server side, acho que dessa vez é completamente diferente pelos motivos que o Diego mencionou.
Achei interessante essa visão, mas como ficam em cenários com times back e front muito grandes? Todos atuando no mesmo repositório n poderia complicar em algo?
sou apaixonado pelo next js, ele facitilita muito quem não conhece back-end a trabalhar com o próprio backend no servidor node dele, mas me sinto um pouco inseguro como aluno do ignite, se vale a pena maximizar ele , ou só ficar no react js, pois no mundo real, eu vejo poucas empresas pedindo next, ao invés disso, eles querem que você saiba uma segunda linguagem como java e foque no backend por ela usando um banco de dados
Fala Raimundo, o Next.js é uma realidade, talvez não em empresas menores em cidades pequenas, mas qualquer empresa que você for trabalhar com um projeto grande em React já vai ter pelo menos passado por tentar o Next.js alguma vez, com certeza é uma ferramenta que vale a pena o estudo, além do mais que continua sendo React, o Next.js não exclui o aprendizado em React em si. Se a empresa pede que você saiba Java além do React, provavelmente é uma empresa menor, porque é praticamente impossível você se tornar especialista em Java e React ao mesmo tempo com ambientes e ecossistemas tão diferentes.
Nossa eu fiz o mesmo, minha API para uma aplicacao para meu game esta usando NextJS, Prisma mais sem API externa, as APIs tambem estao no next, agora esperar chegar la no Ignite para melhorar ainda mais o que ja fiz :D.
A ferramenta certa sempre vem depois de um grande "DEPENDE". Principalmente: Complexidade é custo. Vc pode dividir sua api em 20... com kubernets e etc... mas vc vai ter equipe pra bancar essa estrutura e treinamento para tal ? No começo a grana é curta, só quando da certo que a grana entra e dá pra mudar algumas variaveis... mas até lá o next facilita demais a vida ( ainda mais se vc juntar ao pacote a facilidade que a vercel dá )
Top de mais ... eu acho o Next muito massa mas até hoje não consegui utilizar em um projeto em produção =( .. os que trabalho atualmente usam react vanilla kk
Diego, muito bom esse conteúdo. Um dúvida, para rodar um ambiente NextJS de forma interna, bastaria que o servidor tenha suporte a Node.js ? Por exemplo, tenho um projeto na máquina de desenvolvimento e para fazer o deploy disso no servidor bastaria que o servidor tenha node.js para conseguir rodar esse projeto? Isso sem precisar fazer o next export onde perderia os recursos de servidor.
Diegão, eu acho que sempre foi um framework backend pro React. Ainda não sei como isso funciona pra equipes grandes, mas talvez até reduze a necessidade de uma equipe maior por conta da estrutura que o Next trás.
Mas um monorepo já não é uma forma de trazer o backend e frontend pro mesmo code base, porque usar o Next só porque ele permite essa aproximação na forma de trabalhar? Ou entendi errado.
Eu sempre achei ela Fullstack, so nao era tao usado API dentro do next, ou usado sempre para acessar outra API externa, legado, etc, eu nao faco mais isso, agora construo as APIs dentro do NextJS, e para melhor trabalho em equipe, so criar ela agnostica e separar em modulos no git para as squads, devs, etc. NextJS salva a producao, que para o Cliente/CEO, e o que importa :D.
eu acho legal, mas eu curto essa divisão de tecnologias de frontend e backend... pra mim a melhor estrutura é ter o frontend em react/next e o backend em laravel com php... Acho que o laravel funciona muito bem e tem várias utilidades no backend.
Com o Next.js é possível fazer com que parte das páginas sejam geradas no servidor, e outra parte seja construída dinamicamente no cliente? Se sim, esse é o mundo perfeito. Outros frameworks back-end nos limitam em relação a construção dinâmica no lado do cliente. Usávamos muito o jQuery, com AJAx pra isso. Aí vieram os SPAs, mas apresentaram algumas limitações como bem citadas no video. E agora, usaríamos o melhor dos dois mundos...
Quantidade de arquivos e so olhar algum game project unreal/unity, etc, organizacao vai alem disso, e muita gente erra muito em tentar diminuir a quantidade de arquivos, sempre extendendo infinitamente um componente, etc. Acho que o legal sempre e escrever bem, e documentar, e seguir um padrao que o time trabalhe junto, mais so 100% a favor tudo no mesmo lugar, hoje tambem programando com C++ na Unreal estou passando por isso, Frontend e Backend novamente em um so como no passado, SPA ja passou essa era, logo virao outras arquiteturas.
Vejo valor em várias dessas mudanças e acredito que esse tipo de arquitetura tem espaço no mercado , mas na minha opinião ela se torna um problema quando o projeto cresce muito, pois normalmente você vai ter equipes diferentes trabalhando em módulos separados dentro de um mesmo monolito. Vejo que o grande próximo passo tende a ser evoluir pra uma arquitetura baseada em "micro-modules" (micro-serviço + micro-frontend juntos) dando total liberdade pra cada equipe trabalhar independente e possibilitando que esses módulos se pluguem em uma aplicação container. E para os casos em que o Backend precisar utilizar outra tecnologia, o micro-serviço poderia ser substituído por um backend-for-frontend. Em ambos os casos, vejo vários ganhos para as equipes, como maior autonomia, menos troca de contextos, possibilidade de alterações atômicas que facilitam o deploy, dentre outras.
Excelente video, mas ele me parece muito direcionado a novos programadores que nao sabem como era que funcionavam as coisas... Como falado no vídeo, estamos voltando no tempo em alguns detalhes.. e isto nao é ruim, pelo contrário, é um avanço
Acredito que tanto o Next.js como o Remix estão direcionando a comunidade para uma arquitetura full-stack novamente, como faziam os incas maias e astecas...
Adeus servidores convencionais, Vercel e Amplify são o novo patamar... Next mais aperfeiçoado e um nível acima no mercado e agora ganhando um concorrente que preciso tirar o chapéu, o Svelte...
Não sou muito a favor de usar o Back-end no Next, maaaas acho que seria uma boa ideial talvez utiliza-lo como BFF, existindo um Backend, usar o server side no next para operar como BFF intermediando os dados entre o front e o back
E oq acontece se eu quiser desenvolver o meu backend não só pro frontend em next mas tbm pra um outro frontend em mobile? Vi que vocês usaram nextauth pra implementar a autenticação no next, mas como integrar o mobile nesse caso?
Então, você pode usar a API do Next em qualquer outro ambiente, o ponto é que o Next Auth faz uma camada front-end da autenticação também, você precisaria desenvolver essa parte da autenticação visual no mobile que é abrir a tela de oAuth do Google, pegar o código de autenticação e trocar por um access token e, então, poderia enviar esse código à API do Next.js e continuar usando o Next Auth para criar um JWT, etc...
Olha, acredito que tenho um bom conhecimento mais nunca trabalhei na área, quando se falo do php 2011 eu pensei que começei php 2010, ai falo do angular 3 e eu angular 2 peguei bem na migração da primeira versão do angularjs e já comecei a usar angular 2, mais posso dizer que no react vc esta mais tempo que eu rss, fiquei no angular até versão 7 e depois fui pro react e nunca mais larguei, pois o angular estava horrível já. Tudo que vc fala em todos os video eu tenho conhecimento em algumas coisas tenho um conhecimento até um pouco mais avançado. Eu queria seguir minha carreira nessa aréa mais sou horrível em se comunicar com as pessoas, minha didática é complicado e como tinha um emprego bom e só utilizava como hobby e até hoje ainda não trabalhei na área, e to focado no nextjs des da primeira versão porque acredito que vai ser fullstack de alta performace e me diz ai uma dica de como começa minha carreira, conhecimento eu tenho!
Acho que a única vantagem atual é você não se preocupar com deploy e escalonamento de recursos, dificilmente você vai ter funcionalidades como as do Nest dentro diretamente do Next, pense no Next, por enquanto, apenas sendo um micro-framework back-end estilo Express/Fastify ao invés de ser um framework estilo Nest.
Pra projetos grandes o nextjs é um ótimo BFF (backend for frontend) mas pra ser backend completo de um sistema eu não recomendo, é muito fácil as coisas ficarem bagunçadas. O que eu sinto falta, e vejo que é uma dor da comunidade, é injeção de dependencia, ter uma estrutura semelhante ao Nestjs em questão de ser mais opiniado por back, pq configurar o TSSyringe fazer o setup e organizar pasta dá um trabalho um pouco que chato.
Então, o Next.js segue bem o paradigma de "convention over configuration" trazendo algumas convenções porém poucas configurações mesmo, mas na parte do "back-end" existe pouca convenção, até porque você pode curtir injeção de dependências, mas no geral tem muita gente que não curte, prefere fazer na mão com factories.
Sinceramente falando, acho que tem os seus prós e contras deixar o back-end no mesmo lugar do front-end. Porém, dependendo do caso, é muito mais vantajoso você separar os dois, pois você tem mais liberdade de escolher a linguagem que você quer trabalhar no front e back da aplicação. Dando um exemplo, se fosse um projeto envolvendo processamento de imagens usando Inteligência Artificial, JS na minha opinião, não é a melhor escolha para fazer esse tipo de projeto, um Python ou talvez um C, Rust ou Go seria algo mais adequado, pois são linguagens que fornecem opções de multithread nativamente e possuem libs prontas que resolvem um problema desses com uma certa facilidade.
Suas opiniões são válidas, porém não vejo com bons olhos criar um backend complexo no next, por ele funcionar parecido com o express, ter que configurar muita coisa na mão e se não souber o que está fazendo acaba deixando o código bagunçado de difícil manutenção... ainda gosto de usar adonis, nest, etc pela produtividade, fácil manutenção e oferecer opinião para arquitetura no backend. Se manjar de arquitetura, souber o que está fazendo, pensando no longo prazo, é válido.
Com certeza, acho que você precisa saber o que está fazendo, mas isso é com tudo... eu sempre recomendo pra um time que não tem tanta experiência procurar criar seus projetos com algum framework que traga mais convenções e opiniões pra não precisar ficar tomando muitas decisões.
@@dieegosf que é o meu caso, sou Júnior, então ainda prefiro usar um framework, sei fazer um projeto com express mas não fica o código mais clean do mundo, com padrões de projeto e tal
@@dieegosf Acho que o tópico vai um pouco além de alinhar essas decisões por senioridade. Alguns projetos precisam ter um controle de escala do backend diferente do frontend. Numa aplicação multi cliente manter front e back na mesma estrutura sempre terá um custo de recursos e desenvolvimento. Acho que essa é uma solução que se adequa bem a depender das particularidades do projeto. Um projeto grande, multi cliente e com regras de negócio complexas se beneficia muito mais de um framework como o Nest. Conceitos como injeção de dependência não são apenas uma técnica de gosto pessoal, mas algo que impacta de maneira muito relevante na produtividade. Esse é o tipo de coisa que precisa ser decidido em equipe, com analise e planejamento.
Não sei se concordo, o posicionamento da Vercel nunca foi como um framework back-end apesar dele oferecer essa funcionalidade. Mesmo que o Next.js possua uma camada server-side, o seu foco ainda era usar essa camada para construção de interface, no fim, não existia um posicionamento claro sobre operar no banco, por exemplo, direto dentro do Next.js.
Nossa startup com NextJS+Supabase+Tailwind fomos do MVP pra 150 clientes B2B (com mais de 1 milhões de API calls por semana) em 10 meses. Tudo isso em 3 devs
Opa, quanto você gasta com o supabase por mês? Só por curiosidade, se puder revelar
@@Wesley9xd estamos no plano pro de $25 mensal pra ter backups diários, etc. Mas estamos indo pro plano enterprise que o mínimo é uns 1mil dolares mensais. Aí tu já consegue alguns recursos como suporte 24/7 dedicado, point in time recovery do banco, replicas, etc
@@GabrielSestrem Massa! então pelo que eu vi os limites pagando 25 dólares já são bem generosos né? estava pensando em usar o Supabase
@@Wesley9xd bem generoso sim. Ficamos no free plan por um bom tempo. Errei em usar o storage deles e logo ultrassei o 1gb do free plan. Depois migramos as imagens direto pra AWS S3 e nem precisava mais do plano pago. Mas com eu disse anteriormente, o plano pago tem backups diários e um pouco mais de prioridade no suporte. Eu gosto muito.
@@GabrielSestrem Bom dia, você tem algum email pra entrar em contato?
Estou atualmente fazendo um projeto pessoal justamente usando esse recurso do Next.js, codando o back-end junto ao front , usando prisma e o planetscale como banco de dados e realizar o deploy na Vercel. Realmente é uma ferramenta muito completa.
queria saber mesmo como rodar fora da vercel
@@LucasHenrique-xm8xc Containeriza com o docker e sobe em cloud de sua escolha. AWS te um free tier que dá pra fazer uns testes e usando o docker-machine o processo de deploy é ainda mas simplificado. Dá uma olhada no canal da Rocket que tem um vídeo sobre isso.
@@pidubiu com o docker consigo publicar num servidor com IIS?
é, estamos voltando ao que faziamos antigamente, tudo junto. Eu vejo esse vai e volta o tempo todo.
Só que sem deixar o código poluído no html com mistura de outras linguagens, dava vontade de chorar só de olhar
Que vídeo sensacional. Pra mim que não sou formado na área, tampouco acompanhei a evolução do desenvolvimento web por tanto tempo quanto você, é muito interessante ter acesso a esse tipo de conteúdo. Pq as vezes não faz muito sentido pra mim esse tipo de discussão. Agora faz. Muito bom mesmo.
Diegão, eu construí a Manycontent inteira com servless, iniciei a 4 anos atrás e foi uma ótima escolha.
Excelente vídeo, Diegão! A tua animação é contagiante e inspiradora
Diego, lança um vídeo fazendo um back-end integrado ao Next já usando os novos route handlers
Diegão serverless é bom demais mesmo. A vercel tem suporte pra Python, Ruby, Node e Go. Já fiz alguns CRUD no MongoDB (atlas) usando Python ano passado e subi na vercel tranquilamente, nessa ideia em 19:17.
Eles deram suporte à WebAssembly né e com isso conseguimos executar basicamente qualquer coisa dentro da Vercel, isso é demais mesmo.
Provavelmente vai ser sim, igual muitos outros frameworks como o Ruby on Rails por exemplo.
É incrível o quanto o conteúdo da Rocketseat evoluiu ao longo dos anos. Já fazia algum tempo que eu não consumia os vídeos aqui do canal e voltando agora eu tô impressionado com a qualidade do que tá sendo produzido 👌👏👏
Caralho que versão massa o next implementou. Parabens pelo vídeo Diego show de bola
Bom analisando talvez no futuro só vale a pena quando vc sabe que seu backend irá servir várias aplicações diferentes. fora isso é melhor fazer tudo junto mesmo
Falando em Ignite, quando sai a trilha atualizada de node?
pra portifólio, projetos pequenos e MVP creio que o NextJS seja a melhor opção. Vercel oferece hospedagem muito boa e gratuita.
Também pode ser uma boa opção pra projetos maiores e mais robustos.
Hoje Docker facilita muito o deploy, tanto para back quanto para front, acredito que sua fala para desenvolvedores fullstack se encaixa quando se fala neste ambiente em especifico (js/ ts).
Nossa .... Parece que vc me ouviu kkkk fiz sistema de agendamento para um cliente esses dias em php
nextjs é incrivel ele da a possibilidade do dev front-end criar aplicaçoes completas sem entender muita coisa de back end
O unico problema que vejo de deixar tudo junto, é pra equipes grandes, os deploys ficam mais amarrados, mas ter opções é sempre bom.
Pelo que vi, ta semelhante ao Rails do Ruby, é interessante.
De fato quando trabalhamos com front e back se torna melhor ter os códigos próximos, eu mesmo utilizo muito os workspaces do VS Code para alternar melhor.
Um ponto interessante dessa junção é quando temos comportamentos no front que dependem de dados do back, como tipos de inputs, cores, animações e tamanhos. Se ambos estiverem no mesmo local o tempo de resposta é quase instantâneo de ocorrer, ao invés de tentar encontrar um servidor mais próximo e só então fazer a requisição.
Estou utilizando em um novo projeto e sem dúvidas funciona melhor, ainda mais tendo que utilizar MetaMask e outras carteiras direto do browser para autenticar usuários.
O bom é que não é obrigatório, isso só vai trazer mais vantagem pro lado do Next, por que ainda vai dar pra renderizar components client-side normalmente usando a diretiva 'use client', sem falar que alguns hooks só vão funcionar dessa forma pois não é possível usá-los com server components
Desde o primeiro dia que conheci o Next.js eu pensei em algo voltado nesse sentido, porém é claro que isso veio maturando com as atualizações do Next.js e acho que vale muito conteúdo voltado pra isso. Parabéns Diegão!
Acredito que vai ser back-end e front-end sim, da mesma forma que os framework's Astro, Fresh e cia.
Para um projeto que tenha a certeza que vai rodar somente web esse é o melhor dos mundos. Porém pensando em escalabilidade para mobile e consumo de terceiros melhor desacoplar através de uma api ainda é o melhor caminho.
Eu acredito sim que vai.
Diego, quando vai começar a sair videos com o Remix?
curti o conteúdo!! valeu
Aqui onde trabalho foi desenvolvido 15 MS em NexJS assim como um front PWA
eu considero a evolução natural.
Faaaaala Dev, blzzzz? Show demais Diegao, to fznd um projeto usando nextjs pro front e nest pro back e o legal de ver isso é saber que futuramente posso utilizar somente um framework para todo o processo e vcs da rockseat tem me ajudado muito na evolucao e aprendizado dessas ferramentas e dos conceitos por traz de cada uma. (deixa o tema do seu vscode na descricao, pq eu sou fominha de tema e troco todo dia hahahaha)
Catppuccin for VSCode
Diego sempre com vscode mais lindo, melhores temas haha. Excelente explicação, tenho acompanhado as evoluções do next e o direcionamento que o desenvolvimento web está tomando e fico bastante empolgado. Por mais que o pessoal do PHP esteja zoando esse circulo que o javascript fez de client side de volta pra server side, acho que dessa vez é completamente diferente pelos motivos que o Diego mencionou.
Achei interessante essa visão, mas como ficam em cenários com times back e front muito grandes? Todos atuando no mesmo repositório n poderia complicar em algo?
sou apaixonado pelo next js, ele facitilita muito quem não conhece back-end a trabalhar com o próprio backend no servidor node dele, mas me sinto um pouco inseguro como aluno do ignite, se vale a pena maximizar ele , ou só ficar no react js, pois no mundo real, eu vejo poucas empresas pedindo next, ao invés disso, eles querem que você saiba uma segunda linguagem como java e foque no backend por ela usando um banco de dados
Fala Raimundo, o Next.js é uma realidade, talvez não em empresas menores em cidades pequenas, mas qualquer empresa que você for trabalhar com um projeto grande em React já vai ter pelo menos passado por tentar o Next.js alguma vez, com certeza é uma ferramenta que vale a pena o estudo, além do mais que continua sendo React, o Next.js não exclui o aprendizado em React em si. Se a empresa pede que você saiba Java além do React, provavelmente é uma empresa menor, porque é praticamente impossível você se tornar especialista em Java e React ao mesmo tempo com ambientes e ecossistemas tão diferentes.
Nossa eu fiz o mesmo, minha API para uma aplicacao para meu game esta usando NextJS, Prisma mais sem API externa, as APIs tambem estao no next, agora esperar chegar la no Ignite para melhorar ainda mais o que ja fiz :D.
A ferramenta certa sempre vem depois de um grande "DEPENDE". Principalmente: Complexidade é custo. Vc pode dividir sua api em 20... com kubernets e etc... mas vc vai ter equipe pra bancar essa estrutura e treinamento para tal ? No começo a grana é curta, só quando da certo que a grana entra e dá pra mudar algumas variaveis... mas até lá o next facilita demais a vida ( ainda mais se vc juntar ao pacote a facilidade que a vercel dá )
E lá vamos nós...
Nos 19 min ele falou sobre não executar certos códigos la dentro do back, fiquei intrigado sobre oque fazer e oque não fazer dentro da api do Next
Vais ser tbm eu dei a idéia no Discord
Top de mais ... eu acho o Next muito massa mas até hoje não consegui utilizar em um projeto em produção =( .. os que trabalho atualmente usam react vanilla kk
Acho que e top se deixar agnostico a API totalmente JS e usar no NextJS assim se precisar usar com outras aplicacoes, nao fica dependente do NextJS.
Diego, muito bom esse conteúdo. Um dúvida, para rodar um ambiente NextJS de forma interna, bastaria que o servidor tenha suporte a Node.js ? Por exemplo, tenho um projeto na máquina de desenvolvimento e para fazer o deploy disso no servidor bastaria que o servidor tenha node.js para conseguir rodar esse projeto? Isso sem precisar fazer o next export onde perderia os recursos de servidor.
Estou com esse desafio no meu trabalho, só que tem q sincronizar com o outlook
Como funcionam os testes com o projeto desse jeito?
Temos que ter 2 setups de teste?
Só por curiosidade, a rocket tem parceria ou patrocinado pela Vercel?
Diegão, eu acho que sempre foi um framework backend pro React. Ainda não sei como isso funciona pra equipes grandes, mas talvez até reduze a necessidade de uma equipe maior por conta da estrutura que o Next trás.
#PR como poderia usar a api criada dentro do next para usa no meu app feito com react native?
Basta chamar a api, é uma endpoint comum, só configurar o cors
Sempre achei que o Next.js fosse um framework backend também, se não fosse, pra que serviria então as rotas de API ali ? (Pergunta sincera)
Mas um monorepo já não é uma forma de trazer o backend e frontend pro mesmo code base, porque usar o Next só porque ele permite essa aproximação na forma de trabalhar? Ou entendi errado.
Eu sempre achei ela Fullstack, so nao era tao usado API dentro do next, ou usado sempre para acessar outra API externa, legado, etc, eu nao faco mais isso, agora construo as APIs dentro do NextJS, e para melhor trabalho em equipe, so criar ela agnostica e separar em modulos no git para as squads, devs, etc. NextJS salva a producao, que para o Cliente/CEO, e o que importa :D.
eu acho legal, mas eu curto essa divisão de tecnologias de frontend e backend... pra mim a melhor estrutura é ter o frontend em react/next e o backend em laravel com php... Acho que o laravel funciona muito bem e tem várias utilidades no backend.
Com o Next.js é possível fazer com que parte das páginas sejam geradas no servidor, e outra parte seja construída dinamicamente no cliente? Se sim, esse é o mundo perfeito. Outros frameworks back-end nos limitam em relação a construção dinâmica no lado do cliente. Usávamos muito o jQuery, com AJAx pra isso.
Aí vieram os SPAs, mas apresentaram algumas limitações como bem citadas no video. E agora, usaríamos o melhor dos dois mundos...
É possível. Inclusive dá pra fazer páginas híbridas.
Alguem sabe que tema o diego está utilizando nesse video ?
Só pra não perder o costume, qual o tema do VsCode?
github.com/catppuccin/vscode
dracula
Estão voltando ao formato que era o MVC?
Simplicidade de um framework mvc mas com a reatividade das views em react :D
Pensando em backend, Next seria melhor q o Nest?
Ou seria tão similar quanto os nomes? rs
Nest, foca em back
Next, foca em front
entao pensando em back, é o Nest
Nest ja vem bem estruturado para o back
Uma dúvida, utilizando essa abordagem é possível utilizar a API em outras aplicações por exemplo um aplicativo , ou ela fica atrelada a web?
Quantidade de arquivos e so olhar algum game project unreal/unity, etc, organizacao vai alem disso, e muita gente erra muito em tentar diminuir a quantidade de arquivos, sempre extendendo infinitamente um componente, etc. Acho que o legal sempre e escrever bem, e documentar, e seguir um padrao que o time trabalhe junto, mais so 100% a favor tudo no mesmo lugar, hoje tambem programando com C++ na Unreal estou passando por isso, Frontend e Backend novamente em um so como no passado, SPA ja passou essa era, logo virao outras arquiteturas.
Vejo valor em várias dessas mudanças e acredito que esse tipo de arquitetura tem espaço no mercado , mas na minha opinião ela se torna um problema quando o projeto cresce muito, pois normalmente você vai ter equipes diferentes trabalhando em módulos separados dentro de um mesmo monolito. Vejo que o grande próximo passo tende a ser evoluir pra uma arquitetura baseada em "micro-modules" (micro-serviço + micro-frontend juntos) dando total liberdade pra cada equipe trabalhar independente e possibilitando que esses módulos se pluguem em uma aplicação container. E para os casos em que o Backend precisar utilizar outra tecnologia, o micro-serviço poderia ser substituído por um backend-for-frontend. Em ambos os casos, vejo vários ganhos para as equipes, como maior autonomia, menos troca de contextos, possibilidade de alterações atômicas que facilitam o deploy, dentre outras.
Isso vc já está falando num cenário muito mais complexo do que 90% das aplicações precisam ter
@@aquicnpj sim, concordo com você. Isso aí que eu falei só faz sentido quando vc tem uma aplicação de grande porte, com vários times trabalhando nela.
Excelente video, mas ele me parece muito direcionado a novos programadores que nao sabem como era que funcionavam as coisas... Como falado no vídeo, estamos voltando no tempo em alguns detalhes.. e isto nao é ruim, pelo contrário, é um avanço
Alguém sabe que tema é esse que ele tá usando?
Acredito que tanto o Next.js como o Remix estão direcionando a comunidade para uma arquitetura full-stack novamente, como faziam os incas maias e astecas...
Até os grandes asteroides Monolitos devastarem novamente essas novas sociedades do passado.
esse rumo que web dev tá tomando vai acabar com devops?
Adeus servidores convencionais, Vercel e Amplify são o novo patamar... Next mais aperfeiçoado e um nível acima no mercado e agora ganhando um concorrente que preciso tirar o chapéu, o Svelte...
Como funcionaria se a gente quisesse expor endpoints? O next permite isso ou a gente precisaria usar um express da vida?
Pelo que entendi eh só por um arquivo com o nome da.rota na pasta api que já vira uma rota
Não sou muito a favor de usar o Back-end no Next, maaaas acho que seria uma boa ideial talvez utiliza-lo como BFF, existindo um Backend, usar o server side no next para operar como BFF intermediando os dados entre o front e o back
E oq acontece se eu quiser desenvolver o meu backend não só pro frontend em next mas tbm pra um outro frontend em mobile?
Vi que vocês usaram nextauth pra implementar a autenticação no next, mas como integrar o mobile nesse caso?
Então, você pode usar a API do Next em qualquer outro ambiente, o ponto é que o Next Auth faz uma camada front-end da autenticação também, você precisaria desenvolver essa parte da autenticação visual no mobile que é abrir a tela de oAuth do Google, pegar o código de autenticação e trocar por um access token e, então, poderia enviar esse código à API do Next.js e continuar usando o Next Auth para criar um JWT, etc...
Olha, acredito que tenho um bom conhecimento mais nunca trabalhei na área, quando se falo do php 2011 eu pensei que começei php 2010, ai falo do angular 3 e eu angular 2 peguei bem na migração da primeira versão do angularjs e já comecei a usar angular 2, mais posso dizer que no react vc esta mais tempo que eu rss, fiquei no angular até versão 7 e depois fui pro react e nunca mais larguei, pois o angular estava horrível já. Tudo que vc fala em todos os video eu tenho conhecimento em algumas coisas tenho um conhecimento até um pouco mais avançado. Eu queria seguir minha carreira nessa aréa mais sou horrível em se comunicar com as pessoas, minha didática é complicado e como tinha um emprego bom e só utilizava como hobby e até hoje ainda não trabalhei na área, e to focado no nextjs des da primeira versão porque acredito que vai ser fullstack de alta performace e me diz ai uma dica de como começa minha carreira, conhecimento eu tenho!
Isso traz alguma vantagem relevante, ao invés de usar um Nest no backend?
Acho que a única vantagem atual é você não se preocupar com deploy e escalonamento de recursos, dificilmente você vai ter funcionalidades como as do Nest dentro diretamente do Next, pense no Next, por enquanto, apenas sendo um micro-framework back-end estilo Express/Fastify ao invés de ser um framework estilo Nest.
Quero saber que tema é esse...
Também kk
Pra projetos grandes o nextjs é um ótimo BFF (backend for frontend) mas pra ser backend completo de um sistema eu não recomendo, é muito fácil as coisas ficarem bagunçadas.
O que eu sinto falta, e vejo que é uma dor da comunidade, é injeção de dependencia, ter uma estrutura semelhante ao Nestjs em questão de ser mais opiniado por back, pq configurar o TSSyringe fazer o setup e organizar pasta dá um trabalho um pouco que chato.
Então, o Next.js segue bem o paradigma de "convention over configuration" trazendo algumas convenções porém poucas configurações mesmo, mas na parte do "back-end" existe pouca convenção, até porque você pode curtir injeção de dependências, mas no geral tem muita gente que não curte, prefere fazer na mão com factories.
Vai ter promoção de black friday no Ignite? 👀
Se por promoção você quer dizer desconto, não.
@@dieegosf preço só ta aumentando, queria fazer rematrícula mas com esse valor não dá, não tem promoção, não tem desconto e curso de Node está velho.
Retorno do MVC?
Já virou kk
o Theo já fala que é backend
Oi PHP, é você? kkkk
Sinceramente falando, acho que tem os seus prós e contras deixar o back-end no mesmo lugar do front-end. Porém, dependendo do caso, é muito mais vantajoso você separar os dois, pois você tem mais liberdade de escolher a linguagem que você quer trabalhar no front e back da aplicação. Dando um exemplo, se fosse um projeto envolvendo processamento de imagens usando Inteligência Artificial, JS na minha opinião, não é a melhor escolha para fazer esse tipo de projeto, um Python ou talvez um C, Rust ou Go seria algo mais adequado, pois são linguagens que fornecem opções de multithread nativamente e possuem libs prontas que resolvem um problema desses com uma certa facilidade.
Suas opiniões são válidas, porém não vejo com bons olhos criar um backend complexo no next, por ele funcionar parecido com o express, ter que configurar muita coisa na mão e se não souber o que está fazendo acaba deixando o código bagunçado de difícil manutenção... ainda gosto de usar adonis, nest, etc pela produtividade, fácil manutenção e oferecer opinião para arquitetura no backend. Se manjar de arquitetura, souber o que está fazendo, pensando no longo prazo, é válido.
Com certeza, acho que você precisa saber o que está fazendo, mas isso é com tudo... eu sempre recomendo pra um time que não tem tanta experiência procurar criar seus projetos com algum framework que traga mais convenções e opiniões pra não precisar ficar tomando muitas decisões.
@@dieegosf que é o meu caso, sou Júnior, então ainda prefiro usar um framework, sei fazer um projeto com express mas não fica o código mais clean do mundo, com padrões de projeto e tal
@@dieegosf Acho que o tópico vai um pouco além de alinhar essas decisões por senioridade. Alguns projetos precisam ter um controle de escala do backend diferente do frontend. Numa aplicação multi cliente manter front e back na mesma estrutura sempre terá um custo de recursos e desenvolvimento. Acho que essa é uma solução que se adequa bem a depender das particularidades do projeto. Um projeto grande, multi cliente e com regras de negócio complexas se beneficia muito mais de um framework como o Nest. Conceitos como injeção de dependência não são apenas uma técnica de gosto pessoal, mas algo que impacta de maneira muito relevante na produtividade. Esse é o tipo de coisa que precisa ser decidido em equipe, com analise e planejamento.
mas next já era antes, e continua sendo backend hahaha
Virando? Sempre achei que NextJS era uma framework backend 😐
PHP de Javascript. Só que 100 vezes mais lento
está virando? next.js É back-end pelo amor
caraca, back end realmente não é pra mim
nextjs JÁ É uma framework backend 🤣
sempre foi
Não sei se concordo, o posicionamento da Vercel nunca foi como um framework back-end apesar dele oferecer essa funcionalidade. Mesmo que o Next.js possua uma camada server-side, o seu foco ainda era usar essa camada para construção de interface, no fim, não existia um posicionamento claro sobre operar no banco, por exemplo, direto dentro do Next.js.
Nossa cara, código back dentro de front, que retrocesso.