React frontend na CDN?

Vždycky jsem bral server side rendering jako jedinou možnost, ale nedávno mi docvaklo, že když mám frontend v Reactu a na backend přistupuju jen přes API, tak vlastně můžu celý frontend nasypat na CDN. Máte s tím zkušenosti, je tam nějaký háček nebo to prostě funguje tak jak by člověk čekal? Slibuju si od toho daleko rychlejší loading a taky daleko menší nároky na server, který se bude start jen o API.

ssr bol nutny iba kvoli vyhladavacim enginom(google, yahoo, seznam...) ktore nevedeli js naparsovat a spracovavali tak len ciste html. to sa vsak zmenilo nejake 2-3 roky dozadu a dnes ti google bot naindexuje plne js stranku bez problemov. ja som tak robil prvu taku minuly rok, s vue.js, a je na google zaindexovana. takze ssr je uz prezitok si myslim a len zbytocny problem a naklad.

co sa tyka cdn, nema tam kde byt problem. ak pouzijes cloudflare, ktore ma cdn zdarma pre subory do 100mb, tak mas o jeden problem menej, a ak pouzijes cloud funckie tak prakticky nemas nutnost riesit server a jedine co potrebujes je databaza na ktoru sa tie funkcie budu napajat. cize ten backend sa ti taktiez zjednodusi a zlacni. zalezi samozrejme na konkretnej aplikacii, ake ma poziadavky a tak ale celkovo to je dnes dost v pohode. akurat tie cloudove funkcie nie su dobre pre privela requestov, vtedy su nasobne drahsie nez obycajne lacne vpsko, takze is treba spocitat naklady dopredu potom.

Tak nějak si to představuju...v podstatě i tu databázi nějak přesypu třeba do algolie nebo elasticu a web server mi bude řešit v podstatě jen write akce a invalidaci cache. Cloud funkce, jestli myslíš třeba lambdy na AWS, nechám na pozdějc, zatím je pro mě dost velký konceptuální skok i samotné opuštění SSR :) Super postřehy, díky moc.

Teď pracuji na jednom větším public projektu. Jede to na Create React App. Mám tam vyřešený jednoduchý code splitting, aby nebyl jeden velký JS soubor a i tak musím říct, že silně uvažujeme nad tím, že půjdeme na SSR. Původně jsme CRA vybrali, protože jsme si nebyli jistí routami v Nextjs a nějak jsme nestíhali, tak jsme zvolili technologii, kterou dobře známe a rozumíme jí. Vidíme tam ale mezery v tom, že se uživateli načítá víc dat, než by bylo potřeba (velké JS soubory), dlouho trvá práce v CPU jádru při prvním vykreslení atd. Tohle SSR řeší. Rychlost webu je pak někde jinde, zejména prvního načtení.

Když vezmu v potaz RFC, které teď Next řeší (odkaz na Github), tak si myslím, že je to furt na zvážení. RFC ve zkratce umí vygenerovat JSONy pro dotazy z databáze pro konkrétní stránky tak, aby při prohlížení nebylo třeba dělat dotazy na API, které se nemění, a zrychlí se tak neskutečně uživatelský zážit.

Upřímně mi přijde, že Next.js je takovým super-hybridem mezi CRA a Gatsbym, kterého osobně moc nemusím.

Proč zvažujete SSR? To jsem z toho nějak nepochopil...Kvůli rychlejšímu renderingu initial state?

Ve finále zejména menší bundle size, automatický fetching komponent a hlavně rychlejší initial state. Next.js se nám dost líbí, protože i když SSR úplně nepotřebujete, nabízí ho v podstatě "zadarmo". Důležité pro nás je, že i když víme, jak si code splitting udělat sami, sami si udělat prefetch js souborů, nějaký i prefetch dat třeba když najedu kurzorem na nějaký tlačítko, tak je to poměrně dost práce to odladit.