Nazaj

23. februar 2025, Miha Medven

Testna različica na test.klele.si

Imel sem srečo. Otroci so bili zdravi in imel sem dovolj energije za programiranje. Sem tudi razmislil, kako bi rad zapeljal projekt.

Kaj je sedaj narejeno?

Frontend

Večino kode sem skopiral iz že obstoječega projekta, tako da je bilo treba v resnici samo zastaviti okvirno arhitekturo in se odločiti, kako zapeljati dejstvo, da morajo ostati plače dostopne.

Na koncu sem naredil preprost ”Prihaja kmalu!” in vzpostavil povezave na Github ter na ta blog. Za začetek bo to več kot dovolj.

Prikaz spletne strani z napisom 'Prihaja kmalu'

Čeprav sama spletna stran še nima nobene funkcionalnosti, je dovolj napredka, da jo lahko splavim in začnem kazati okoli. Meni je predvsem ključno, da drugi ljudje lahko vidijo napredek. Le tako dobiš povratne informacije glede tega ali se premikaš v pravo smer. Hkrati pa tudi kažeš drugim, da si se resno lotil projekta.

Backend

Ko enkrat začneš lokalno povezovati zadeve, hitro ugotoviš, da ti manjkajo podatki. Predvsem sem malo zgrešil strukturo in kako se API odziva na requeste.

Večina strežnikov spoštuje ”accept” headerje v requestih, in ti vračajo za header primeren format. Različne knjižince (npr. Axios) v ozadju same dodajajo header ”accept: application/json”, ki ga potem strežnik prebere in vrne JSON response. Za enkrat ne vidim potrebe po spoštovanju tega headerja in vedno vračam le JSON.

Druga stvar je sama struktura podatkov, ki jih vračam. Včasih se ti splača na frontendu narediti več klicov, spet drugič je lažje na backendu nadgraditi kak klic, da so vsi podatki poslani skupaj. Ker se poskušam držati REST(ful) arhitekture, vsaj na začetku precej eksperimentiram s tem, kakšna bo končna struktura.

Te eksperimente si na začetku z veseljem privoščim, saj le jaz uporabljam ta API.

Deploy

Tukaj se je v resnici največ zgodilo.

Za Next.js sem se med drugim tudi odločil, ker ima v resnici dober SSR (Server Side Rendering), kar mi omogoča dober SEO, hkrati pa mi olajša cachiranje rezultatov za neprijavljenje obiskovalce. Največja pomanjkljivost SSR je predvsem v povezovanju med sistemi.

Tako imamo 3 sisteme:

  1. Client (frontend, ki se poganja v brskalniku)
  2. SSR server
  3. API server
Diagram za komunikacijo med sistemi

Odločil sem se, da bosta API klicala tako SSR server kot tudi koda v brskalniku. Kdo bo klical kaj, bo odvisno od tega ali je uporabnik prijavljen ali ne.

Uporabnik ni prijavljen

SSR izvede klic na API, pridobi podatke, jih zapakira v HTML in vrne uporabniku. Klasičen SSR pristop za namene SEO in hitrosti.

Uporabnik je prijavljen

SSR vrne uporabniku prazno client kodo, ki ob prikazu znotraj brskalnika naredi klic na API, da prikaže prispevke.

Ne bom uporabil Next.js kot BFF (Backend For Frontend), ker se bo client povezoval direktno na API.

Github actions in testna različica

Celoten deployment gre prek Github actionov, ki se prek SSHja povežejo na mojo Digital Ocean inštanco in naredijo kar morajo narediti. Za lažji razvoj sem ustvaril nov branch imenovan ”develop”, ki se avtomatsko servira na test.klele.si.

Kaj sledi?

Prijava in možnost objavljanja prispevkov.