SPA болон SSR-н талаар
Энэ пост дээр сайн муу талуудын жагсаалт оруулахгүй зөвхөн миний өөрийн бодлын талаар оруулъя гэж бодлоо.
Энэ талаар өмнө хэдэн пост уншиж байсан. Мэдээж маш олон өнцгөөс бичиж тайлбарласан байдаг. Тэр дундаас түүж бичих зүйл маань SPA яаж уламжлалт веб хөгжүүлэлтээс хурдан ажиллагаатай байдаг, SPA-н асуудал болоод SSR хэрхэн түүнийг шийдэж байгаа, яагаад SSR-г зөв ашиглахгүй бол шийдэл бус илүү ажил вэ? нар юм.
SPA-н үндсэн санаа нь хуудас render хийх ачааллыг броузерт шилжүүлэх ба түүний үр дүнд серверийн ачаалал буурч, сервер броузерын хооронд үүсэх холболтын тоо буурч, дамжих датаны хэмжээ багасах юм. Ингэснээр тодорхой хуудсыг харуулах нийт хугацаа багасах юм. Ajax дээр суурилсан маш гоё шийдэл ба үүний ачаар веб апп-н хөгжил багагүй хэмжээгээр өссөн гэж боддог.
SPA нь эхлээд үндсэн хуудсыг татаж аваад түүндээ өөрийн динамикаар үүсгэсэн контентуудаа угсрах замаар ажилладаг. Гэтэл яг энэ хүү динамик процесс нь давуу талууд ихтэй ч бас нэг томхон сөрөг талтай. Тодорхойлбол хөгжүүлэгдэж буй сайт нь мэдээлэл бүхий контент дээр суурилсан байгаад тэрхүү контентууд нь хайлтын систем дээр index-жүүлэх (бүртгэх гэхээр сонин сонсогдож байна) шаардлагатай бол SPA тийм ч зөв сонголт биш.
Яагаад ийм асуудал үүсэж байна вэ гэвэл, хайлтын систем-үүдийн веб crawler-ууд сайтын хаягуудруу ээлжлэн ороод доторх мэдээллийг процесс хийдэг. Ингэж процесс хийхэд resource файлуудыг огт ашиглахгүй. Учир нь уламжлалт аргаар бол resource-ууд нь контент өөрчлөх, өнгө үзэмж хийгээд агуулгын хувьд байж болно, хийхээс бүхэлд нь үүсгэдэггүй. Мөн resource-г дуудаж ашиглана гэдэг нь зүгээр мэдээллийг унших энгийн зүйлийг маш төвөгтэй болгож байгаа юм.
Resource дуудна, дахиж render хийнэ, хийхдээ уг resource-оо давхар процесс хийнэ, resource-г дуудахад алдаа өгвөл яах вэ? дахиад дуудах уу? гэтэл resource нь бүүр байхгүй 404 өгвөл яах вэ? гээд энд дурдсан дурдаагүй маш олон асуудлуудыг веб crawler-т шийдэх хэрэгтэй болно. Бас нэг анхаарах зүйл нь зүгээр контент уншдаг байсан crawler resource татаад ирэхээр ачаалал нь үлэмж ихсэж таарна, үүүүү түм буман сайт дунд ингээд ажиллана гэж төсөөлөхөөр …
За тэр ч яахав, одоо мэдээлэл дээр суурилсан сайтууд яах вэ? (Энэ дунд мэдээний болон блогууд орох юм.) Мэдээллээ нийтэд хүргэхийн тулд хайлтын систем дээр заавал index-жүүлэх хэрэгтэй. Шийдэл нь SSR. Сервер тал дээр render хийчихвэл crawler хуудсруу ороход мэдээлэл нь бэлэн байж байх тул асуудал гарахгүй. Бас орчин үеийн react, vue, angular гээд framework ашиглаж байгаа болохоор хурдан, бүх асуудал шийдэгдлээ, тийм үү? Тийм биш ээ. SSR гээд чамин нэртэй энэ ойлголт уламжлалт гэх даруухан нэртэй зүйлтэй дэндүү ижилхэн. Харамсалтай нь үүнийг огт өөр мэтээр ойлгож хамгийн буруугаар буюу зөвхөн render-т зориулсан backend үүсгэж хэрэглэх тохиолдол байна.
API Backend + Rendering backend + Frontend нэг иймэрхүү зүйл үүсэж байгаа юм. Зөв гаргалгаа нь API backend нь энгийн бүтэцтэй бол шууд шууд backend дээрээ rendering нэмж өгөх API байх шаардлагатай бол hybrid байдлаар оруулж өгөх. Жишээ нь: Content-Type header-р text/html утга ирвэл html буцаагаад application/json байвал json утга буцаадаг ч юм уу байдлаар шийдэх нь зөв болно. Мөн microservices юм уу эсвэл олон public API-тай ажилладаг сайт байлаа гэхэд түүнд нэг дата цуглуулах сервер ашиглах хэрэгцээ байдаг тэгвэл энэ сервер дээр мөн render хийх хэсгээ оруулбал хамаагүй зөв шийдэл болох юм.
Тодорхой шийдэл гэвэл Ruby on Rails фрэймвөрк нь asset pipeline гэх зүйлтэй бөгөөд үндсэн ажиллагаа нь static контентын хүргэлтийг хариуцдаг. Тэгвэл webpacker гээд нэмэлт байдаг ба энэ нь webpack-г asset pipeline-тай хамт ашиглах боломж олгоно. Үүний ачаар орчин үеийн frontend фрэймвөркүүдийг сервер талдаа рендер (SSR) хийгээд html response буцаах боломжийг олгож байгаа юм. Бусад хэл, фрэймвөрк, хэрэглэлүүдэд мөн иймэрхүү байдлаар шийдэл хийж өгч явах нь л хамгаас зөв арга юм.
Анхаарал тавьсан явдалд баярлалаа.
