התקנה והגדרה של Saleor מקצה לקצה: Django + GraphQL

התקנת Saleor: היכן נשבר פריסה עצמאית

התקנת Saleor בכוחות עצמך נראית כמו פריסה רגילה של פרויקט Django: להעלות את האפליקציה, להריץ מיגרציות, לחבר מסד נתונים ומטמון. אבל בדרך כלל זה לא נשבר בשלב הזה, אלא בממשקים — כאשר החנות מתחילה לעבוד תחת תנועה אמיתית ומערכות חיצוניות.

השכבה הראשונה של תקלות — הקטלוג. מוצרים, וריאציות ומלאי מגיעים ממערכת הנהלת החשבונות, אבל כרטיסי המוצר נערכים גם באדמין: בלי בעלים ברור לנתונים, כל סנכרון דורס עריכה של אחר. בחלון הראווה מופיעים פריטים עם מלאי אפס ומחיר ישן, והפער בין חלון הראווה לביצוע ההזמנה צף כבר ברגע התשלום.

השכבה השנייה — עגלה והזמנות. אם ביצוע ההזמנה עובר דרך כמה שלבים בלי טרנזקציה אחת ובלי שריון מלאי, בעומס שיא ביום מכירות חלק מהעגלות הולכות לאיבוד, וההזמנות משוכפלות. הלקוח רואה חיוב אחד, המחסן — שתי בקשות, והבירור אורך יום, לא דקות. שלמות הקטלוג וההזמנות נשענת לא על ניסיונות חוזרים, אלא על פעולות אידמפוטנטיות ונעילות מלאי מפורשות.

השכבה השלישית — אינטגרציות: תשלום, משלוח, מחסן, תפוצות. בשיא הן מקבלות פי כמה יותר בקשות, ובלי תורים עם הגבלת מקביליות משימות רקע מצטברות, התראות ממערכות חיצוניות הולכות לאיבוד, וסטטוסים של הזמנות מפסיקים להתאים למשלוח בפועל. בהמשך נסביר איך זה נסגר בעת פריסת פלטפורמת ecommerce.

סכמת קטלוג והזמנות גמישה: מה נותנת ההגדרה

כרטיס מוצר הוא לא רשומה אחת, אלא קבוצת וריאציות: צבע, מידה, הרכב, שלכל אחת מלאי ומחיר משל עצמה. מודל נתונים תקין של הקטלוג מקשר וריאציות, מחסנים וערוצי מכירה באופן מפורש, ולכן חלון הראווה מציג רק את מה שזמין בערוץ הנדרש.

ב-Saleor הסכמה הזו מובנית כברירת מחדל, אבל דורשת הגדרה — אחרת מופיעים כפילויות של מוצרים ופער בין חלון הראווה למחסן.

קטלוג, וריאציות ומחסנים

מאפיינים אנו מתארים בשדות טיפוסיים, לא בטקסט חופשי: מסננים ואוספים נבנים לפי אינדקסים, לא בכוח גס. קטגוריות אנו בונים כעץ עם עומק צפוי, כדי שתפוקה לפי מדור לא תמשוך את כל הקטלוג.

שריון אנו מפרידים מהמלאי בפועל: כל עוד ההזמנה לא אושרה, המוצר נשאר זמין לשאר הקונים, והמחסן לא מציג "מינוס".

שכבת חלון הראווה ועומסי שיא

שכבת חלון הראווה בונה את עמוד הקטלוג באמצעות בחירות מוכנות מראש במקום מפל של בקשות: זמן התגובה יורד לשברירי שנייה במקום שניות ולא גדל עם עומק הקטלוג.

תפוקה בשיא אנו בודקים בהרצות על פרופיל אמיתי — מכירה, קמפיין פרסומי, גל עונתי — ומביאים למצב שבו חלון הראווה מחזיק את הזרימה בלי תור.

ביצוע ההזמנה מתבצע בפעולה אחת: חיוב מלאי, יצירת הזמנה ורישום היסטוריית סטטוסים לא מתפצלים זה מזה. שליחה חוזרת של הטופס לא יוצרת הזמנה שנייה, וניתוק בשלב התשלום לא משאיר שריון קפוא. נעלם סוג התקלות: "מכרו משהו שאין" ו"יש הזמנה אבל אין פריטים".

מצבי פריסה: השוואת אפשרויות

הבחירה באפשרות פריסה קובעת כמה מהר יוצא עדכון Saleor, עד כמה האפליקציה תעבור באופן צפוי את גידול הקטלוג ומי אחראי לגישה לנתונים. להלן שלוש סכמות שביניהן באמת בוחרים בהתחלה.

מה משתנה בעת הרחבה

בסכמת קונטיינרים שכבת האפליקציה לא שומרת מצב, ולכן חלון הראווה מתרחב ברפליקות, ותור משימות הרקע מוצא בנפרד וגדל באופן עצמאי. שאילתות GraphQL נשמרות במטמון, בחירות כבדות של הקטלוג עוברות לרפליקות של מסד הנתונים — העגלה וביצוע ההזמנה נשארים על הצומת הראשי.

מעבר בין אפשרויות מתבצע בהעברת דאמפ של מסד הנתונים וקובצי מדיה, ולכן הסכמה הנבחרת לא נועלת אותך: נבחן איזה מתאר סוגר את המגבלות שלך בגישות ובעומס.

סדר התקנת Saleor: מביקורת עד מסירה

סדר העבודות בנוי כך שכל שלב נשען על התוצאה של הקודם: תחילה מתעדים את המצב בפועל של המתאר, אחר כך מתכננים את הסכמה, ורק לאחר מכן נוגעים במתאר העבודה. להלן שלבי ההטמעה כפי שהם מתנהלים בפרויקטים עם תנועה חיה.

1. סקר תשתית. מתעדים את התמונה הנוכחית: מיקום השירותים, מבנה מסדי הנתונים, מגבלות השרתים, הכלים שבשימוש הצוות. בתום — דוח עם צווארי בקבוק שמשפיעים ישירות על סכמת הפריסה.
2. תכנון הסכמה. מגדירים את הרכב הרכיבים של Saleor, סכמת אחסון הנתונים, תפקידי השירותים, נקודות אינטגרציה עם מערכת הנהלת החשבונות והתשלום. את הטופולוגיה מתאמים לפני תחילת העבודות.
3. הפרדת סביבות. מקימים מתארים נפרדים לפיתוח, לקבלה ולתפעול — עם מסדי נתונים, מפתחות וקונפיגורציה משל עצמם. עדכונים נבחנים על עותק של נתונים ולא פוגעים בקונים.
4. התקנה והגדרה. פורסים את האפליקציה, תורי משימות רקע, אינדקס חיפוש ומטמון, מגדירים מיגרציות וגיבוי — תחילה במתאר בדיקה.
5. בדיקת עומסים. מדמים תרחישים אמיתיים: צפייה בקטלוג, עגלה, ביצוע הזמנה, ייצוא. בוחנים זמן תגובה בשיא והתנהגות המערכת בכשל של צומת נפרד.
6. מסירת הפרויקט. מוסרים גישות ותיעוד לפריסה ולשחזור, מכשירים את הצוות, מתעדים תקנון עדכונים ונשארים לתמיכה.

הרכב האספקה: קונפיגורציות, סכמות ותקנונים

אספקה היא לא ארכיון עם קוד, אלא סט ארטיפקטים שלפיהם אפשר לתפעל ולפתח את המערכת בלי המחבר. כל מה שמוגדר בהתקנת Saleor מתועד במאגר ובתעוד: קונפיגורציות, סכמות, מדיניות ותקנונים עוברים ללקוח.

• קונפיגורציות הפרויקט — קובצי סביבה לפיתוח, למתאר בדיקה ולמתאר עבודה, משתני חיבור למסד נתונים ולתור, סודות מוצאים בנפרד.
• סכמת אינטגרציות — מפת קשרים עם תשלומים, משלוחים, מחסן ומערכת הנהלת חשבונות: כיוון החליפין, פורמט הנתונים, התנהגות כשאין נגישות לצד החיצוני. בנפרד מתואר הממשק התוכנתי שלפיו מתחברים חלון הראווה והאפליקציה לנייד.
• מדיניות גישה — תפקידים והרשאות להזמנות, לקטלוג ולמחירים; הגבלות כניסה לאדמין ולשיטות שירות.
• סכמת נתונים ומיגרציות — מבנה הקטלוג (מוצרים, וריאציות, קולקציות, מחסנים), כללי מילוי וסדר העברה מהמערכת הקודמת.
• תקנון עדכונים — תדירות עדכון הפלטפורמה והתלויות, בדיקה במתאר בדיקה, נקודות שחזור.
• ניטור ויומנים — מדדים נאספים, ספי חירום, מסלול התראות.
• תיעוד וצ'ק-ליסט קבלה — הוראות למנהלים ולמפתחים, תרחישי בדיקה לפני העלאה.

הרכב כזה מסיר את התלות בקבלן: מהנדס חדש נכנס למערכת לפי סכמות ותקנונים, לא לפי הזיכרון של הצוות הקודם.

מקרה בוחן: העברת קטלוג בלי לעצור מכירות

חנות על פלטפורמה ישנה החזיקה קטלוג של 40+ אלף פריטים, והסנכרון של המלאי התבצע במנות וחסם את חלון הראווה: הייצוא ארך עד 40 דקות, בזמן הזה כרטיסים לא נפתחו, וחלק מההזמנות המנהלים ביצעו ידנית. פערים במלאי ובמחירים הגיעו עד 8% מהפריטים — התמיכה עסקה בהם מדי יום, במקום לעסוק בקונים.

ההעברה בוצעה בלי לעצור מכירות. מתאר חדש על Saleor הוקם במקביל למתאר העבודה: הקטלוג והיסטוריית ההזמנות נשלחו במנות לכתיבה, החנות הישנה המשיכה לקבל הזמנות. בזמן הטעינה, שינויים מקבילים הגיעו בנוסף, ומפתחות אידמפוטנטיות לא אפשרו לכפילויות להיכנס לקטלוג.

מה השתנה

המעבר של חלון הראווה עבר בלי השבתה: הקונים לא ראו לא עמוד תחזוקה ולא שגיאות ביצוע, ולחזור למתאר הישן במקרה של סטייה ניתן היה בפקודה אחת. זמן התגובה של הקטלוג במסננים כבדים התקצר כמעט פי שלושה — האינדקס והמטמון נבנים מחדש ברקע, לא בכל בקשה.

מדדים לאחר

• השבתת החנות: אפס במקום כמה שעות מתוכננות.
• ייצוא הקטלוג: מ-40 דקות לכמה דקות בודדות, חלון הראווה נשאר זמין.
• פניות לתמיכה בנושא "אין מוצר / המחיר לא נכון": פחות פי ארבעה.
• פערי מלאי: מ-8% מהפריטים לשברי אחוז.

הזמן שהתפנה בתמיכה הוקדש לייעוץ ולעבודה עם לקוחות סיטונאיים, לא לבירור פערים. חיבור ערוץ מכירה חדש כעת לא דורש ייצוא נפרד — הקטלוג יוצא ממקור אחד.

במה שונה פריסה מאפס מהעברת חנות?

פריסה מאפס — התקנה נקייה של Saleor: את סכמת הקטלוג מתכננים לפי המשימה, ולא יורשים מהפלטפורמה הקודמת. מאפיינים, וריאציות מוצר, מחסנים וכללי מחירים מוגדרים ישר במודל הנדרש, אינטגרציות מתחברות למסד נתונים ריק. היקף העבודות — הגדרה ובדיקת תרחישים, לא העברה.

העברת חנות — משימה הפוכה: לשמר עסק עובד ברגע החלפת הפלטפורמה. מעבירים קטלוג, קטגוריות, מאפיינים, מלאי, היסטוריית הזמנות ומשתמשים. הקושי העיקרי — אי-התאמה של סכמת הקטלוג: מה שבפלטפורמה הקודמת היה ישות אחת, כאן מתפרק לכמה ודורש המרה מפורשת.

מיגרציית נתונים עוברת דרך ביקורת: מה מעבירים כמו שזה, מה בונים מחדש, ומה לא לוקחים. הייצוא מתבצע בפורמט ניטרלי, הטעינה — עם בדיקת התאמה: מספר הפריטים, המלאי, המחירים ושיוך ההזמנות צריכים להתאים לפני ואחרי. פערים מחפשים במתאר בדיקה, לא במסד הנתונים הקרבי.

תאימות אינטגרציות — הסיכון הגדול השני של המעבר. שערי תשלום, שירותי משלוחים, מחסן והנהלת חשבונות מחליפים נתונים לפי החוזים שלהם: חלק מתחברים באמצעים מובנים, חלק דורשים פיתוח. כתובות ישנות של כרטיסים וקטגוריות מופנות לחדשות בהפניות קבועות.

מכאן המסקנה: פריסה מאפס צפויה מבחינת לוחות זמנים, מעבר — שלבים ותוכנית שחזור. בקטלוג קטן ובמספר קשרים מצומצם, התקנה נקייה עם טעינת נתונים חוזרת מהירה יותר.

מגבלות הפלטפורמה ושאלות טכניות נפוצות

הפלטפורמה סוגרת קטלוג, עגלה וביצוע הזמנה מהקופסה, אבל יש לה גבולות — כדאי להכיר אותם לפני ההשקה. להלן ספקות שנשמעים לרוב בהערכה, ואיך אנחנו מסירים אותם ברמת הארכיטקטורה.

איך משלבים מחסן ומערכת הנהלת חשבונות?

מלאי, מחירים וסטטוסים של הזמנות עוברים דרך API — לפי לוח זמנים ולפי אירועים. עדיפות המקור נקבעת מראש: המחסן מכתיב את המלאי, החנות — את המחיר, ופערים עוברים ליומן ולא הופכים למכירה של מוצר שאינו קיים.

מה עם תשלומים ואבטחה?

שער מתחבר בקונפיגורציה, התשלום מתבצע עם אימות ב-3-D Secure. נתוני כרטיסים לא עוברים דרך האפליקציה — משתמשים בטוקניזציה בצד הספק, ולכן מתאר הביקורת נשאר צר, וספק התשלומים מוחלף בלי לשכתב את חלון הראווה.

באיזה סדר יוצאים עדכוני הפלטפורמה?

ענף ראשי חדש אנחנו לא מעלים ביום השחרור: תחילה מתקן ביניים, הרצת תרחישי הזמנה ומיגרציות נתונים, אחר כך העלאה עם אפשרות שחזור. עדכונים יוצאים במנות.

נדון במשימה: מה צריך להערכה ולהתחלה

כדי לדון במשימה באופן ענייני ולחזור עם הערכת פרויקט, ולא עם מילים כלליות, אנחנו צריכים גבולות עבודה. להלן סט מינימלי של נתוני מקור. אם משהו עדיין אין — לא קריטי: חלק נברר בשיחה, חלק נאסוף בעצמנו במהלך הניתוח.

• קטלוג: כמה מוצרים וקטגוריות, אילו מאפיינים ווריאציות (מידות, אפשרויות), מאיפה מעבירים נתונים.
• מודל מכירות: חלון ראווה אחד או כמה, שפות ומטבעות, האם נדרשים מחסנים שונים וכללי משלוח.
• תשלום ולוגיסטיקה: אילו ספקי תשלום ושירותי משלוחים מחברים, האם יש תרחישים לא סטנדרטיים כמו תשלום חלקי או איסוף עצמי.
• אינטגרציות: ERP, מחסן, CRM, אנליטיקה — מה ובאיזה כיוון צריך להחליף נתונים עם Saleor.
• עומס: תנועה צפויה בשיא, מספר קונים במקביל, דרישות לזמן תגובה של הקטלוג וביצוע ההזמנה.
• תשתית: היכן ממקמים את הפרויקט, איזה מתאר קיים כעת, מי אחראי לגישות, לדומיינים ולתעודות.
• מגבלות: תאריך השקה, התחייבויות כלפי שותפים, מה כבר מוכן בתוכן ובעיצובים.

על בסיס זה צוות מהנדסים מקבע את ההיקף, מפרק אותו לשלבים ומוסר תוכנית עבודה ולוחות זמנים עם הנחות מפורשות ונקודות תיאום. תארו את המשימה בצורה נוחה — נחזור עם הערכה ותוכנית.