ראשית כל: איך זה הסתיים
אם אתם רוצים לדלג על כל הסיפור ופשוט לראות את התוצאה, הנה המידע:
- flaming.codes נכתב מאפס (לכן יכונה v2 מעתה) וכעת משתמש ב-Qwik ו-Qwik City כפריימוורק הבסיסי, קודם לכן השתמש ב-Next.js
- הסרתי את כל התלות ב-CMS צד שלישי ובשכבת ה-Caching ומארח כעת את כל התוכן ב-מאגר ה-Github של אפליקציה זו (Progressive Web App)
- עשיתי זאת מכיוון ששמתי לב שתחזוקת כל מחסנית הטכנולוגיה של v1 של flaming.codes הייתה עבודה מרובה מדי - התיק האחרון היה כשהייתי צריך לעדכן את ה-CMS (Sanity) והייתי צריך לכתוב מחדש קצת מהתוכן בכל מקרה
- רכיב התרגום של v1, שכלל סידור מחדש של מסמכים ותרגום דרך Google Translate, הוחלף בתוכן markdown טהור ו-OpenAI's GPT-4](https://openai.com), בהתאמה
- לא הטמעתי עדיין את תכונת ה-TTS (טקסט לדיבור), אבל אעשה זאת בעתיד הקרוב תוך שימוש בדגמי Whisper של OpenAI
- flaming.codes עדיין מתארח ב-Vercel, אבל כעת משתמש ב-Edge Functions לשרת את האתר, במקום ב-Build Output API, מכיוון שכרגע אין אדפטר פריסה זמין מ-Qwik City
- העיצוב עודכן גם כן וכעת תומך במצב אור ומצב חושך תוך שימוש ב- Windy Radix Colors כדי להביא את צבעי Radix כמחלקות Tailwind
ה-CMS הלך, שיחייך ה-CMS
הסיבה הראשונה שכתבתי את גרסת v2 של flaming.codes הייתה כדי להפחית תלויות בשירותים:
- הסרת CMS (ומערכת ה-CDN שלו) וניהול כמו גם אירוח כל התוכן (פוסטים, קטגוריות, נכסים ועוד) ישירות במאגר, שיהיה גם פתוח למשתמשים
- כחלק מהמעבר הזה, הסרת שכבת ה-caching עבור תוכן ה-CMS, מכיוון שזה כבר לא נחוץ
- החלפת השימוש ב-Google Translate ושירות הדיבור לטקסט של Microsoft עם API-ים מ-OpenAI
מעבר מ-CMS מתקדם כמו Sanity ומחולל השאילתות הדינמי שלו בא עם מחיר של צווארון החויבות ליישם ניהול תוכן (קל) בעצמי. אני לא רוצה לדאוג לעדכון ותחזוקה של חלק כה מרכזי בפרויקט. המטרה שלי היא שהפיתרון הזה יעבוד גם אם לא אכתוב פוסט במשך שנה, כי הדרישה היחידה אמורה להיות פתיחת המאגר, כתיבת מאמר ואז פשוט לדחוף שינויים לזרם העיקרי כדי להפעיל פריסה חדשה.
אתם יכולים לבדוק את תיקיית /cms בשורש הפרויקט ב-GitHub כדי לראות את הקוד המקורי בעצמכם. זה עובד די טוב, זה ישר לעניין ולגמרי עצמאי, לא נדרש חשבון נוסף והתחברות ל-CMS. חווית העריכה עכשיו אפילו יותר עוצמתית מבעבר, כי עכשיו אני יכול להשתמש ב-Markdown לכל התוכן, שהוא הרבה יותר פשוט לכתיבה ותחזוקה מאשר עורך ה-Sanity המותאם אישית. הוספתי אפשרות טעינת מחדש בזמן אמת עבור הריצת סקריפט העורך, כך שאוכל לראות את השינויים בזמן אמת - אם אני רוצה אפילו למספר שפות בו זמנית.
אני אתן פרטים נוספים על ה-CMS בפוסט נפרד.
למה בחרתי ב-Qwik ו-Qwik City במקום ב-Next.js
Qwik והפריימוורק המלא שלו הנקרא "Qwik City" נשמעו לי מעניינים מההתחלה: טעינה עצלה של כל JS באופן אוטומטי עד שהם באמת נחוצים בלי כל hydration. בהקשר של flaming.codes, היתרונות מארכיטקטורה זו הם מתערבים, כי האתר שלי בלב עצמו הוא בלוג. ככל שיש יותר רכיבים ואינטרקציות באפליקציה האינטרנטית, כך גדלים השיפורים שמגיעים משימוש ב-Qwik. עם זאת, הייתי סקרן ורציתי לחוות זאת בעצמי.
תמיכה בתרגום לשונות ב-Qwik לעומת Next.js
flaming.codes מתורגם ל-14 שפות, כולל כמה בכיוון ימין לשמאל. כאשר בדקתי לראשונה את Qwik בתחילת 2023 (כעשרה חודשים לפני שביצעתי את הכתיבה מחדש האמיתית של v2), הרגשתי שאין פתרון אמיתי לתמיכה בתרגום לשונות, והמאמצים שלי מעבר לכמה ניסיונות ראשוניים דעכו.
כאשר הסתכלתי על זה שוב בדצמבר, qwik-speak היה הפתרון הנחוץ כדי לאפשר תרגומים ב-flaming.codes, אז הוצאתי את הבסיס הישן מהאבק והתחלתי בכתיבת הקוד מחדש.
מתרגם חדש
הערימה הישנה השתמשה ב-API של Google Translate, ששירת אותי יפה, אבל כל רכיב בא עם כמה מורכבות:
- תוכן של שפה מקורית הוא נלקח מ-Sanity CMS, נפרס ונחתך לבלוקים ביניים
- כל בלוק הוא מתורגם לשפות היעד הזמינות
- הבלוקים המתורגמים בונים מחדש כך שהתוכן המקורי, כולל העיצוב, משוחזר וזמין עבור ה-Frontend לשימוש
זה עבד מספיק טוב, אבל הקוד היה יחסית קשה לקריאה ותחזוקה.
flaming.codes כעת משתמש ב- OpenAI לתרגום כל התוכן. הכל כולו הרבה יותר פשוט:
- מאמר חדש מוכתב ב-Markdown טהור
- המאמר נשלח ל-OpenAI ומתורגם בשלמותו
- המודלים של LLM מספיק חכמים בכך שהם רק מתרגמים את חלקים הרלוונטיים, אבל לא למשל את כל ה-frontmatter (מורה מנחה את ה-LLM לפי אילו שדות לא צריך לבצע את התהליך)
פריסה ב-Vercel
Qwik City יכולים להיכנס לשדה כאתר סטטי (SSG), אבל זה יכול להוביל למצב שבו לא ניתן להשתמש בנקודות קצה דינמיות, לכן flaming.codes משתמש ב-"Vercel Edge"- אדפטר לצורך פריסה ואירוח נמשכים דרך Vercel. הייתי מעדיף שה-"Build Output API" של Vercel גם יהיה זמין כאדפטר, אבל לעת עתה זה מספיק.
ל-flaming.codes בעבר נעשה שימוש ב-Build Output API, שאומר שקוד שרת צדדי נעשה בש
