Que aula SENSACIONAL!!! O algoritmo do RUclips dessa vez mandou muito, canal e projeto maravilhoso. Didática do professor supimpa, ótimo vídeo. Parabéns
Bom tutorial, contudo ao fazer uma consulta na API a cada letra digitada pode gerar muitas requisições desnecessárias e rapidamente exceder o limite de taxa (rate limit) da API.
Fala @Franca! Obrigado pelo feedback. No final do vídeo foi feito um debounce para isso (último capítulo aqui no YT). Mas claro sempre é possível otimizar de outras formas também. Para o tutorial, o objetivo foi simplificar e focar nos Server Components do Next 😄
@@codante-io Tentei colocar um loading na paginação usando suspense, mas ele funciona somente na primeira vez que a página carrega. Você conhece alguma outra forma de colocar um loading na paginação?
Eu nunca usei o Tanstack table - quero muito testar :) Certamente vai ter mais funcionalidades já "out of the box" (ordenação, paginação, etc), então em produção eu provavelmente usaria algo do tipo. Abraços!
Tanto a documentação como a API em si é open-source Bernardo! Só dar uma fuçada no nosso github para encontrar os repos. Qualquer coisa chama a gente no Discord que a gente te ajuda por lá!
Acho que enxerguei um possível problema, se você muda a URL, a page home não é sempre reenderizada sempre que você faz uma alteração na URL ? Ao invés de reenderizar apenas a listagem
Fala Maycon, não sei se entendi exatamente a pergunta - me corrija se não é isso. Se mudarmos a URL manualmente, sempre haverá uma nova renderização de toda a página (por SSR). Ao clicar em algum link dentro da página, aí apenas os itens que mudarem serão recalculados e renderizados
Fala Pedro! Obrigado pelo elogio Uso o screenbrush no Mac. E é sensacional - recomendo pra todo mundo 😊 No Windows existem algumas alternativas tipo o epic pen, ppInk e gInk
Boa tarde, tenho uma dúvida: se a paginação é recomendada ser feita sempre no backend, por que bibliotecas como a TanStack Table oferecem paginação 100% no lado do cliente? Existe algum contexto onde é possivel gerar a paginaçao no lado do cliente sem problema?
Boa tarde! Quando estamos lidando com um volume grande de dados, é melhor paginar sempre no backend - imagina ter que carregar na memória centenas de milhares (ou milhões) de itens. Para sets de dados menores, aí a paginação pode ser feita client-side. No caso da TanStack Table, a lib suporta tanto paginação client-side como server-side - então você é quem escolhe como fazer. Quando é um set de dados menores (ou quando a API não traz os dados paginados), nesse caso é razoável paginar client-side :). A vantagem de paginar client-side é a velocidade (não é necessário fazer um request para cada página).
tutorial de como pedir dinheiro emprestado pra pagar a AWS rsrsrsrs, fazer query direto no banco de dados desse jeito ai além de criar filas vai elevar gastos com infra, a ideia é bacana, mas pra isso acontecer recomendo que a quesry seja em cache e não direto em uma base de dados.
@@icaroharry8465 sim, mas pense nisso em um sistema com bastante acessos, geralmente o que se faz nesses casos é gerar um cache de dados básicos, como por exemplo somente o id e o nome da pessoa e enviar tudo ao front, pois ficar fazendo essas pequenas querys ao banco em um grande conjunto pode travar a aplicação.
Fala Marcos! Fazer query simples na DB é uma operação extremamente otimizada. Se tivessemos uma DB com milhões de entradas, a DB é feita justamente pra isso; colocar tudo em cache seria provavelmente inviável ou por a memória do servidor ter que ser gigantesca (cache na memória) ou por ser mais lenta (se fosse um cache em arquivo, por exemplo). Acho que talvez a única forma de otimizar mais ainda seria usando um servidor de busca estilo elasticsearch ou algolia. Para otimizar ainda mais, podemos fazer um debounce (que eu fiz no final do vídeo) Me diga se concorda! Abs 😊
Pra quem quiser mais conteúdo de Next.js se cadastra no nosso site: codante.io
Temos uma trilha só de projetos e workshops de Next 😄
Que aula SENSACIONAL!!! O algoritmo do RUclips dessa vez mandou muito, canal e projeto maravilhoso. Didática do professor supimpa, ótimo vídeo. Parabéns
Muito obrigado pelos elogios, @chustaffus9342!
Depois dá uma olhada no nosso site que tem muito mais conteúdo lá: codante.io
Se tu quer dominar Next.js, MongoDB, Fastify, Redis e Kafka na prática, CrazyStack Node e React do devdoido é o corre.
Sou muito fã do Codante! Direto ao ponto 🎯
Obrigado @kinerikin!
Excelente vídeo!
Obrigado Denisio!
Cara, o video que eu mais precisava. Top Demaisssss
Valeu pelo elogio, Abel.
Depois dá uma olhada no nosso site que temos muito mais conteúdo lá codante.io
Ganhou mais um inscrito
🤩
cara tu é muito foda obg msm😄😘
Fala Matheus! Obrigado pelas palavras!
Cara!! Top demais o vídeo, percebi muito a inspiração do Sam selikoff!!! O cara é foda
Sim sim, gosto muito dele! :) Obrigado pelo comment!!
Bom tutorial, contudo ao fazer uma consulta na API a cada letra digitada pode gerar muitas requisições desnecessárias e rapidamente exceder o limite de taxa (rate limit) da API.
Exatamente! No finalzinho do vídeo eu resolvo isso usando o hook useDebounce()!
Fala @Franca! Obrigado pelo feedback.
No final do vídeo foi feito um debounce para isso (último capítulo aqui no YT). Mas claro sempre é possível otimizar de outras formas também.
Para o tutorial, o objetivo foi simplificar e focar nos Server Components do Next 😄
@@codante-io Verdade, assisti até o penúltimo, obrigado!!
Sensancional a aula, lembrando que a api já estava muito completa então facilitou demais, mas parabéns pelo conteúdo
Valeu Lucas! Se tiver interesse em como desenvolvemos a API, também é open source no github do Codante! Abs!
Mto bom. Obrigado
Valeu Filipe!
excelente aula
Valeu Giselly!
Você poderia trazer o backend dessa aplicação neh, essa api parece tão organizada
Fala Maycon! A API é open source e você consegue ver todo o backend dela no repo (spoiler: é em Laravel): github.com/codante-io/api-service abs!
@@codante-io Ser em Laravel doeu no coração, mas obg ! Vou dar uma olhada mesmo assim
Muito bom!!!
Valeu, Gabriel!
@@codante-io Tentei colocar um loading na paginação usando suspense, mas ele funciona somente na primeira vez que a página carrega. Você conhece alguma outra forma de colocar um loading na paginação?
Teria aula de como realizar este lindo front end? Foi utilizado o shadcn ui?
Boa sugestão! Usamos sim, @johnnatagomes7829 !
Muito bom, cara. Conteúdo muito rico. Você acha fazer melhor dessa forma do que o usando TanStack Table?
Eu nunca usei o Tanstack table - quero muito testar :)
Certamente vai ter mais funcionalidades já "out of the box" (ordenação, paginação, etc), então em produção eu provavelmente usaria algo do tipo.
Abraços!
Sensacional, como vocês criaram a documentação da API?
Fala Bernardo!
Criamos com Starlight (que é um framework baseado no Astro). Dá uma olhada que é bom demais usar!
Tanto a documentação como a API em si é open-source Bernardo! Só dar uma fuçada no nosso github para encontrar os repos. Qualquer coisa chama a gente no Discord que a gente te ajuda por lá!
@@RobertoCestari Muito obrigado, mano! Eu estou à procura pra fazer uma documentação da minha API que pretendo abrir.
Valeu mesmo.
tudo com o prisma
Otimo video. Tenho um app em prod com searchparams vindos da pagina, e nao funcionam, eles vem undefined sabe o porque ?
Fala Eduardo! Depois se quiser, entra na nossa comunidade no Discord, alguém pode tentar te ajudar com isso!
Parabéns pelo conteúdo foda! ❤ Qual seria o app pra desenhar na tela?
Fala Nelio! Uso o screenbrush no Mac (não sei se está disponível para windows). E é sensacional - recomendo pra todo mundo 😊
@@RobertoCestari obrigado! Sucesso para você e espero que continue fazendo conteúdo ótimos como esse 👏👏
cursor-pointer é apenas um estilo, não controla o click
Fala Filipe! Consegue me dizer o minuto em que eu falo? Abs!
Acho que enxerguei um possível problema, se você muda a URL, a page home não é sempre reenderizada sempre que você faz uma alteração na URL ? Ao invés de reenderizar apenas a listagem
Fala Maycon, não sei se entendi exatamente a pergunta - me corrija se não é isso. Se mudarmos a URL manualmente, sempre haverá uma nova renderização de toda a página (por SSR). Ao clicar em algum link dentro da página, aí apenas os itens que mudarem serão recalculados e renderizados
Muito bom o video,
Como voce faz para sinalizar em Amarelo o que voce quer comentar sobre diretamente na tela?
Fala Pedro! Obrigado pelo elogio
Uso o screenbrush no Mac. E é sensacional - recomendo pra todo mundo 😊
No Windows existem algumas alternativas tipo o epic pen, ppInk e gInk
Boa tarde, tenho uma dúvida: se a paginação é recomendada ser feita sempre no backend, por que bibliotecas como a TanStack Table oferecem paginação 100% no lado do cliente? Existe algum contexto onde é possivel gerar a paginaçao no lado do cliente sem problema?
Boa tarde! Quando estamos lidando com um volume grande de dados, é melhor paginar sempre no backend - imagina ter que carregar na memória centenas de milhares (ou milhões) de itens. Para sets de dados menores, aí a paginação pode ser feita client-side.
No caso da TanStack Table, a lib suporta tanto paginação client-side como server-side - então você é quem escolhe como fazer.
Quando é um set de dados menores (ou quando a API não traz os dados paginados), nesse caso é razoável paginar client-side :). A vantagem de paginar client-side é a velocidade (não é necessário fazer um request para cada página).
@@codante-io obg :). Excelente material
qual tema vc está usando?
Fala Rafael - One Dark Pro!
qual é a aplicação uqe está sendo utilizada para marcar as coisas na tela?
Chama-se screenbrush!
tutorial de como pedir dinheiro emprestado pra pagar a AWS rsrsrsrs, fazer query direto no banco de dados desse jeito ai além de criar filas vai elevar gastos com infra, a ideia é bacana, mas pra isso acontecer recomendo que a quesry seja em cache e não direto em uma base de dados.
@@icaroharry8465 sim, mas pense nisso em um sistema com bastante acessos, geralmente o que se faz nesses casos é gerar um cache de dados básicos, como por exemplo somente o id e o nome da pessoa e enviar tudo ao front, pois ficar fazendo essas pequenas querys ao banco em um grande conjunto pode travar a aplicação.
Fala Marcos!
Fazer query simples na DB é uma operação extremamente otimizada.
Se tivessemos uma DB com milhões de entradas, a DB é feita justamente pra isso; colocar tudo em cache seria provavelmente inviável ou por a memória do servidor ter que ser gigantesca (cache na memória) ou por ser mais lenta (se fosse um cache em arquivo, por exemplo).
Acho que talvez a única forma de otimizar mais ainda seria usando um servidor de busca estilo elasticsearch ou algolia.
Para otimizar ainda mais, podemos fazer um debounce (que eu fiz no final do vídeo)
Me diga se concorda! Abs 😊