javascript - Varför anropa extern API på servern i Next JS 13?

Jag behöver lite mer detaljer som stöd för denna fråga: Förklara datavalidering på nytt i Next JS 13

Jag använder de nya Next JS 13 appkatalogfunktionerna för datainhämtning; som Next JS 13-dokumentationen anger, i avsnittet med titeln 'Fetching Data on the Server' på den här sidan:

När det är möjligt rekommenderar vi att hämta data på servern.

Dokumentationen talar om hur de nya teknikerna för datainhämtning, som serveråtgärder och routhanterare, tillåter klientkomponenter att kommunicera med servern för att hämta data, istället för att hämta den direkt i klienten. Serveråtgärder och routhanterare används för att skapa dedikerade API:er med direkt åtkomst till en databas; dock använder jag Supabase, och Supabase genererar ett API åt mig för att kommunicera med databasen.

Som ett resultat överväger jag om det är vettigt för mig att göra mina Supabase API-anrop på en serveråtgärd eller routhanterare, eller (eftersom Supabase API redan är värd på en Supabase-server) om ett klientbaserat API-anrop är okej.

Specifikt angående Next JS-rådet att hämta data på servern och sedan anropa den genererade API:n (serveråtgärd eller routhanterare), är jag lite förvirrad; medan serveråtgärder och routrar kan göra API-anrop åt mig, är detta ens nödvändigt? Eftersom jag gör ett anrop till en dedikerad API-rutt som serveras någon annanstans istället för ett direkt databas-anrop, varför inte bara göra anropet från klienten (till exempel fetch API eller react query, direkt i en klientkomponent). Hur skulle detta vara annorlunda än att anropa en serveråtgärd eller routrutt, eftersom dessa ändå bara genererar API:er som kan anropas från klienten?

Svar #1

Jag bestämmer personligen om jag vill hämta från backend eller frontend med följande överväganden.

  1. SEO-perspektiv - Om datan är statisk och behöver visas för sökmotorer, måste du hämta den från servern och förladda den så att så snart sökmotorerna ser den, ser de all avsedd information för SEO. (dvs om du har en kändisinformationswebbplats, vill du att /info/celeb/FooBarJohn-sidan innehåller information om FooBarJohn så snart sökmotorn ser den.)
  2. Belastning på servern - om datan är mindre viktig att visa för crawlers, skulle du hellre välja att hämta den på frontend eftersom det flyttar all belastning till frontend-användarnas dator och minskar belastningen på din server.
  3. Ett annat SEO-perspektiv - Saker som är mycket dynamiska (t.ex. viss aktieinformation) kan hämtas från klienten om du inte vill att informationen ska samlas in av crawler.
  4. Estetik/funktionalitet - om du alltid vill ladda hela sidans information direkt utan skelett (den laddande användargränssnittet innan hämtning) vill du använda server-sidans hämtning eftersom det skulle garantera att användaren ser informationen så snart de laddar sin sida.
  5. Caching - Du kan cache från frontend med SWR, men du kan nu också cache från backend med hjälp av nya next.js 13 funktioner. (https://nextjs.org/docs/app/building-your-application/caching#overview) Nu kan du lagra ofta använda supabase-anrop för att minska belastningen på supabase-databasen. (Men kom alltid ihåg att caching kan göras i vilket steg som helst av dataflödet. Du kan cache på frontend vs next.js vs tredjepartsleverantör som cache:ar förfrågningar)
  6. Dölja URL - du kan dölja att du använder supabase om du använder route handlers för att skapa anpassade API:er. Användare kan undersöka dina supabase fetch-anrop från F12-konsolens nätverksflik. Prova F5 efter att ha öppnat nätverksfliken på din app.