React frontend na CDN?

9. 12. 2019 12:14:04

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.

9. 12. 2019 12:14:04

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427829

node

(5 hodnocení)

9. 12. 2019 12:20:43

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.

9. 12. 2019 12:20:43

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427828

PetrP

9. 12. 2019 12:42:25

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.

9. 12. 2019 12:42:25

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427827

Petr Homoky

(7 hodnocení)

9. 12. 2019 13:01:44

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.

9. 12. 2019 13:01:44

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427826

PetrP

9. 12. 2019 13:08:19

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

9. 12. 2019 13:08:19

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427825

Petr Homoky

(7 hodnocení)

9. 12. 2019 13:12:32

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.

9. 12. 2019 13:12:32

https://webtrh.cz/diskuse/react-frontend-na-cdn/#reply1427824

Pro odpověď se přihlašte.

Přihlásit