Eerstens: hoe alles geëindig het
As jy die hele storie wil oorslaan en net die resultaat wil sien, hier gaan jy:
- flaming.codes is van nuuts af herskryf (en sal van hier af as v2 bekend staan) en gebruik nou Qwik en Qwik Stad as sy onderliggende raamwerk. Voorheen het dit Next.js gebruik.
- Ek het alle afhanklikhede verwyder wat verwant is aan die derdeparty CMS en Kaslaag en gasheer nou alle inhoud in die Github-repo van hierdie PWA (Progressiewe Webtoepassing).
- Ek het dit gedoen omdat ek opgemerk het dat die instandhouding van die hele v1-stapel van flaming.codes te veel werk was - die laaste strooi was toe ek die CMS (Sanity) moes opdateer en sommige dinge in elk geval moes herskryf.
- Die v1 vertaalkomponent, wat 'n aangepaste dokument-ontleder en vertaling via Google Translate ingesluit het, is vervang deur suiwer markdown-inhoud en OpenAI se GPT-4, onderskeidelik.
- Ek het nog nie die TTS (Teks-na-Spraak) funksie geïmplementeer nie, maar ek sal dit in die nabye toekoms doen deur gebruik te maak van OpenAI se Whisper model.
- flaming.codes is steeds op Vercel aangebied, maar gebruik nou Edge Funksies om die webtuiste te dien in plaas van die Bou-uitvoer API, aangesien daar tans geen ontplooiingsadapter daarvoor deur Qwik Stad verskaf word nie.
- Ontwerp is ook opgedateer en ondersteun nou beide ligte en donker modus deur gebruik te maak van Windy Radix Kleure om Radix Kleure beskikbaar te stel as Tailwind klasse.
Die CMS is weg, lank leef die CMS
Die primêre rede waarom ek v2 van flaming.codes geskryf het, was om diensafhanklikhede te verminder:
- verwyder CMS (en sy CDN) en bestuur asook huisves alle inhoud (poste, kategorieë, bates, ens.) direk in die bewaarplaas, wat ook oop bron sal wees.
- as deel van hierdie oorgang, verwyder die kasielaag vir inhoud van die CMS, aangesien dit nie meer nodig is nie.
- vervang die gebruik van Google Translate sowel as Microsoft teks-na-spraak met API's van OpenAI.
Die oorskakeling weg van 'n kragtige CMS soos Sanity en sy dinamiese navraagbouer kom ten koste van die implementering van 'n paar (liggewig) inhoudsbestuurself. Ek wil nie omgee oor die opdatering en instandhouding van so 'n kernstuk van die projek nie. My doel is om hierdie oplossing te laat werk selfs as ek nie 'n jaar lank 'n pos skryf nie, want die enigste vereiste moet wees om die bewaarplaas oop te maak, 'n artikel te skryf en dan net veranderinge op die hoof te stoot om 'n nuwe ontplooiing te aktiveer.
Jy kan die /cms-gids aan die wortel van die projek op GitHub inspekteer om die bronkode vir jouself te sien. Dit werk redelik goed, is reguit en heeltemal selfstandig, geen ekstra rekening en aanmelding vir 'n CMS benodig nie. Die bestaande ervaring is nou eintlik kragtiger as voorheen, aangesien ek nou Markdown vir alle inhoud kan gebruik, wat baie makliker is om te skryf en te onderhou as die aangepaste redigeerder van Sanity. Ek het 'n lewendige herlaai-opsie bygevoeg vir die hardloop van die redigeer-skrip, sodat ek die veranderinge in werklike tyd kan sien - as ek wil selfs vir veelvuldige tale gelyktydig.
Ek sal in 'n aparte pos meer in detail gaan oor die CMS.
Waarom ek Qwik en Qwik Stad bo Next.js verkies het
Qwik en sy Volledige Stapelraamwerk genaamd "Qwik Stad" het vir my van die begin af baie intrigerend geklink: lui laai van enige JS outomaties totdat dit eintlik nodig is sonder enige hidrasie. In die konteks van flaming.codes is die winste van hierdie argitektuur verminder, aangesien my webtuiste in sy kern 'n blog is. Hoe meer komponente en interaksies 'n webtoepassing het, hoe groter is die verbeterings wat kom van die gebruik van Qwik. Nietemin was ek nuuskierig en wou ek eerste-handse ondervinding daarmee kry.
i18n in Qwik in vergelyking met Next.js
flaming.codes is vertaal in 14 tale, insluitend sommige wat van regs na-links geskryf is. Toe ek die eerste keer na Qwik gekyk het aan die begin van 2023 (ongeveer 10 maande voor ek die eintlike v2-herskrywing gedoen het), het ek gevoel dat daar geen regte oplossing vir i18n was nie, en my pogings buitekant sommige aanvanklike toetse het vervaag.
Toe ek dit weer in Desember bekyk het, was qwik-speak die oplossing benodig om vertalings in flaming.codes moontlik te maak, so ek het die ou kodebasis afgestof en die herskrywing afgeskop.
'n Nuwe vertaler
Die ou stapel het die Google Translate API gebruik, wat my goed gedien het, maar die hele komponent het met 'n bietjie kompleksiteit gekom:
- inhoud in die oorspronklike taal is van Sanity CMS afgehaal, ontleed en in tussenprodukte verdeel.
- Elke brokkie is dan in die beskikbare doeltale vertaal.
- Die vertaalde brokkies is heropgebou sodat die oorspronklike inhoud, insluitend formatering, herstel en beskikbaar was vir die Frontend om te gebruik.
Dit het goed genoeg gewerk, maar die kode was relatief moeilik om te lees en in stand te hou.
flaming.codes gebruik nou OpenAI om alle inhoud te vertaal. Die hele opset is baie eenvoudiger:
- nuwe artikel word geskryf in gewone Markdown.
- die artikel word na OpenAI gestuur en as 'n geheel vertaal.
- LLM's is intelligent genoeg dat hulle net die relevante dele vertaal, maar nie bv. die hele voorstuk nie (‘n kennisgewing gee riglyne aan die LLM in terme van watter velde nie aan die prosedure onderhewig moet wees nie).
Ontplooiing op Vercel
Qwik Stad kon uitgevoer word as 'n statiese webtuiste (SSG), maar dit sou beteken dat ek nie dinamiese eindpunte kon gebruik nie, daarom gebruik flaming.codes die "Vercel Edge"-adapter vir voortgesette ontplooiing en hosting via Vercel. Ek sou graag wou hê dat die "Bou-uitvoer API" van Vercel ook beskikbaar moes wees as 'n adapter, maar vir nou is dit voldoende.
flaming.codes het voorheen die Bou-uitvoer API gebruik, wat beteken het dat bedieningskant-kode Node.js-API's gebruik het - op Vercel Edge, is dit nie meer moontlik nie, aangesien dit 'n effens vreemde en verwarrende mengsel van Web en Node.js APIs is. Dit het my genoodsaak om sommige komponente vir verenigbaarheid te herskryf.
KI en deursigtigheid
Alhoewel dit nie gereed is vir die aanvanklike vrylating van v2 nie, sal ek die metadata-eienskappe vir nuwe artikels opdateer om meer inligting in te sluit oor watter aspekte van 'n artikel met KI geskep is.
In dieselfde skuif sal ek ook die analises van die webtuiste publiek beskikbaar maak om deursigtigheid verder te bevorder. flaming.codes gebruik Plausible.io, 'n privaatheid-respekterende analitiese diens vir basiese gebruikaggregering.
'n Nuwe ontwerp
As deel van die hele herskrywing het ek ook die ontwerp 'n bietjie opgedateer. Dit is soortgelyk op meeste bladsye, maar met 'n vars laag verf.
Nuwe kleure + ligte en donker modus
Dankie aan Windy Radix Kleure, was dit maklik om ondersteuning vir ligte en donker modus te implementeer aangesien die biblioteek al die kleur variante vir beide modusse verskaf.
Ek gebruik nou die Radix Kleur palet as 'n Tailwind-inprop, wat kom met 'n versigtige seleksie van kleurvariasies sowel as maklike ondersteuning vir 'n ligte/donker modus. Ek het ook oorgeslaan na Lucide Ikone aangesien hulle beskikbaar is via 'n biblioteek vir Qwik. Vir vergelyking, hier is 'n paar skermkiekies van die ou ontwerp:
Gevolgtrekking en wat's volgende
Die v1 van flaming.codes het my baie goed gedien sedert sy aanvanklike bekendstelling, maar ek het gevoel die stapel moes vereenvoudig word in die rigting van afhanklikhede van ander dienste.
Dit het my ongeveer twee weke geneem om die herskrywing te voltooi. Inhoudsbestuur sal van nou af baie eenvoudiger wees en my ook help om oortollige kosten te vermy.
Weergawe 2 van flaming.codes het nie funksiepariteit met v1 bereik vir sy bekendstelling nie, maar ek sal die ontbrekende kenmerke in die komende weke toevoeg, soos die hou/van-nie-van-knoppie of die TTS (Teks-na-Spraak) funksie.
