O sonho: um painel rico em dados que todo desenvolvedor adora um painel rico em dados. Para o nosso aplicativo de rastreamento de fitness, Gymlog, queríamos dar aos usuários uma visão abrangente de seu progresso. Isso significava criar um painel com vários cartões de estatísticas: Total Sessions Records Personal Volume levantado Exercícios mais frequentes Atividade Mapas de calor As falhas pareciam ótimas, mas sob o capô, tinha um segredo caro. O problema: quando “em tempo real” fica “muito caro”, nosso back-end é o Firebase e nossos dados vive no Firestore. Cada um desses cartões estatísticos no painel exigia uma ou mais consultas para o Firestore para calcular seu valor. Uma carga única pode desencadear 10, 15 ou até 20 operações de leitura. Para um usuário, tudo bem. Mas o que acontece quando você tem centenas de usuários verificando o painel diariamente? Ou um único usuário que refresca a página cinco vezes em um minuto? 5 Atualize * 20 leituras/atualização = 100 lê os números aumentam assustadoramente rapidamente. Estávamos constantemente preocupados em atingir os limites diários de cotas gratuitos no Firestore, que fechariam o fluxo de dados do nosso aplicativo ou começariam a aumentar uma conta séria. Os dados não mudam com tanta frequência – é improvável que o “exercício mais frequente” de um usuário mude de um minuto para o outro. Atingir o banco de dados em todas as visualizações de página foi incrivelmente ineficiente. A solução: Next.js App Router Caching É aqui que entra o poder do roteador de aplicativos. Esta foi a solução perfeita para o nosso problema. Em vez de fazer com que nossos componentes do lado do cliente busquem dados diretamente (e repetidamente), movemos nossa lógica de busca de dados para os componentes do servidor. A chave é usar a API de busca nativa, que o próximo.js se estende com os recursos de cache. A mágica está na próxima opção. Ele permite que você implemente uma estratégia “obsoleta e revalidada”. Aqui está o conceito: a primeira vez que um usuário solicita a página, buscamos os dados da Firebase e renderizamos a página. Next.js armazenam em cache o resultado desses dados buscando o servidor. Para os próximos x segundos (nosso período de reavalidação), qualquer outro usuário (ou o mesmo usuário atualiza) que solicita que a página receba os dados em cache instantaneamente, sem nunca tocar em nosso back -end da Base Fire. Após o passar do X segundos, a próxima solicitação ainda receberá os dados em cache (obsoleto), mas em segundo plano, o Next.js acionará uma nova busca para revalidar e atualizar o cache com novos dados. Isso nos dá o melhor dos dois mundos: cargas de página em chamas e operações de banco de dados em massa reduzida. Colocando -o em prática, vejamos uma versão simplificada de como implementamos isso para um componente TotalSessionsCard. Primeiro, criamos uma rota interna da API para abstrair a lógica do Firebase. Isso mantém nosso código SDK do Admin Firebase com segurança no servidor. src/app/api/stats/total-sessions/route.ts importar {nexTroSponse} de “Next/Server”; importar {getfirestore} de “Firebase-Admin/Firestore”; importar {adminApp} de “@/lib/FireBase”; // A inicialização do seu aplicativo de administrador // Esta função fala com nossa função Async GetTalsisssions (UserID: String) {const db = getFirestore (adminApp); const sessionsRef = db.collection (`usuários/$ {userId}/sessions`); const snapshot = aguarda sessionsRef.count (). get (); return snapshot.data (). contagem; } // O manipulador de rota da API Exportar a função Async Get (request: request) {// Em um aplicativo real, você obterá o UserID da sessão autenticada const userID = “a-sample-user-id”; tente {const totalSessions = aguarda getTalsessions (userID); return nexTrosponse.json ({toTalsessions}); } catch (error) {return new nexTroSponse (“erro interno do servidor”, {status: 500}); }} Digite o modo de saída do modo de tela cheia agora, em nossa página do painel (que é um componente do servidor), podemos buscar esses dados usando a busca especial que o Next.js fornece. src/app/[locale]/dashboard/page.tsx import {TotalSessionscard} de “@/components/totalSlessionscard”; /Esta é a função de busca de dados para nossa função assíncrona getDashboardstats () {// Este URL é interno ao nosso próximo.js servidor const }); if (! res.ok) {// manipula os erros retornar {TotalSessions: 0}; } return res.json (); } exportar o painel Async PadrinBoardPage () {const {TotalSlesssions} = aguarda getDashboardStats (); retornar (

); } Digite o modo de tela cheia de tela de saída do modo de tela cheia, observe isso a seguir: {Revalidate: 3600}. Essa é toda a implementação. Com essa linha, dissemos a Next.js: “busque esses dados, mas depois cache -os por uma hora”. Agora, não importa quantas vezes o usuário atualize o painel nessa hora, isso resultará apenas em uma única operação de leitura contra nossa API e, portanto, apenas uma consulta ao Firestore. Os resultados O impacto foi imediato e dramático: redução de 95%+ nas leituras: Nossas operações de leitura do Firestore para o painel despencou. Cargas de página mais rápidas: as cargas de página subsequentes são instantâneas à medida que são servidas no cache. Economia de custos: Nossa conta do Firebase agora é insignificante e previsível. Melhor experiência do usuário: o painel parece rápido e responsivo. Essa abordagem foi um divisor de águas para o nosso projeto. Isso nos permitiu construir a rica e pesada experiência de dados que imaginamos sem o medo dos custos descontrolados. Se você estiver construindo um aplicativo Next.js com um back-end como o FireBase, recomendo aproveitar o cache embutido. É simples, poderoso e incrivelmente eficaz. Cache feliz!

Fonte