בלוג ← N8N VS MAKE
מה זה n8n, ומתי כלי אוטומציה ויזואלי מפסיק להספיק
השאלה מה זה n8n מגיעה אלי בדרך כלל אחרי שמישהו ראה סרטון שבו גוררים חמש קופסאות ומקבלים מערכת. הכלי אמיתי והוא באמת עושה את זה. מה שהסרטון לא מראה הוא איפה הלוח הוויזואלי מפסיק להספיק, וזו השאלה היקרה מבין השתיים. בניתי אוטומציות בכלים ויזואליים ובניתי אותן גם בקוד, ולכן המאמר הזה עוסק בגבול ביניהם ולא בשבחים.
מה זה n8n בשלוש שורות
n8n הוא כלי לבניית תהליכי עבודה אוטומטיים על לוח ויזואלי. כל קופסה על הלוח מבצעת פעולה אחת במערכת חיצונית: שולפת רשומה מ-CRM, שולחת הודעה, מייצרת מסמך, קוראת למודל שפה.
שני דברים מבדילים אותו מרוב הכלים בקטגוריה. אפשר להריץ אותו על שרת שלכם ולא רק בענן של הספק, ואפשר לשתול בתוך התהליך קטע קוד כשהלוח לא מספיק. שתי היכולות האלה נשמעות טכניות ומשנות בפועל את התשובה לשאלה מתי תיתקעו.
n8n מול Make: שלושה הבדלים שמרגישים אחרי חודש
ההשוואה הזו נמכרת בדרך כלל כטבלת יכולות, וזה החלק הכי פחות שימושי בה. שני הכלים מחוברים למאות שירותים ושניהם יבצעו את התהליך הראשון שלכם. ההבדל מתגלה בחודש השני.
ההבדל הראשון הוא איפה זה רץ. Make הוא שירות ענן בלבד. את n8n אפשר להעמיד על שרת שלכם, וזה משנה שני דברים: לאן זורם מידע רגיש של הלקוחות, ומה קורה כשמודל התמחור של הספק משתנה.
ההבדל השני הוא יחידת החיוב. כל אחד מהם סופר יחידה אחרת, ולכן שתי החשבוניות אינן ברות השוואה ישירה. אותו תהליך בדיוק יכול להיראות זול בכלי אחד ויקר בשני, תלוי אם הוא רץ הרבה פעמים עם מעט צעדים או מעט פעמים עם הרבה צעדים.
ההבדל השלישי הוא עקומת הלמידה מול תקרת הגמישות. Make נוח יותר ביום הראשון. n8n מתחיל להשתלם כשהתהליך מסתבך, בדיוק בגלל שתי היכולות מהסעיף הקודם.
למה השוואת מחיר לחודש כמעט תמיד שגויה
הטעות הנפוצה היא להשוות את מחיר החבילה הבסיסית. זה מספר שלא אומר כלום כל עוד לא יודעים כמה יחידות חיוב התהליך שלכם צורך בפועל.
הדרך שאני עובד לפיה הפוכה. לוקחים תהליך אמיתי אחד ומריצים אותו פעם אחת על נתונים אמיתיים, ואז קוראים כמה יחידות הוא צרך בפועל, ולא כמה קופסאות מצוירות על הלוח.
ספירת הקופסאות מטעה במיוחד ב-Make, ושם היא נופלת על ההבדל המרכזי בין שני הכלים. Make מחייבת לפי אופרציות, ומודול מבצע אופרציה לכל חבילה (bundle) שנכנסת אליו. זו הנקודה שמפילה את החישוב: מודול שמקבל 100 רשומות כחבילה אחת מבצע אופרציה אחת, ואותן 100 רשומות שנכנסות כ-100 חבילות, למשל אחרי איטרטור או ממודול חיפוש שמחזיר שורה-שורה, מבצעות 100. ניסיונות חוזרים אחרי כשל נספרים גם הם, ולסוגי מודולים שונים יש חריגים משלהם. n8n בחבילות המאוחסנות מחייבת לפי הרצות שלמות של תהליך, ומספר הרשומות בתוך ההרצה לא משנה את החיוב. אותו תהליך עצמו יכול להיראות זול בהשוואה על הנייר ויקר פי כמה בחשבון הראשון, ולכן אל תסמכו על התיאור הזה ולא על שלי: תנאי החיוב משתנים, והמספר שקובע הוא מונה האופרציות של הרצה אמיתית מול דף התמחור בתאריך שבו אתם קוראים אותו. ההרצה העצמית מוסיפה לחישוב עלות שרת, גיבוי ותחזוקה, ורוב ההשוואות באינטרנט משמיטות אותה כי היא לא מופיעה בשום דף מחירים.
שלושת הסימנים שהכלי הוויזואלי נשבר
אלה שלושת הסימנים שאני מחפש כשלקוח שואל אם הגיע הזמן לעבור לקוד:
- הלוח כבר לא נקרא. כשצריך להתחקות אחרי שלושים קופסאות כדי להבין למה משהו קרה, היתרון של הייצוג הוויזואלי התהפך לחיסרון.
- אין רשת בדיקות שרצה מעצמה. לבדיקה חד-פעמית יש דרך בשני הכלים: n8n מריץ צעד או תהליך ידנית עם נתונים נעוצים, ול-Make יש הרצת בדיקה אחת. אבל אף אחד מהם לא נותן חבילת בדיקות שרצה בכל שינוי ומכסה גם את המקרים שלא חשבתם עליהם. קוד לא נותן את זה מעצמו, הוא רק מאפשר: את הבדיקות, המקרים והריצה האוטומטית בכל שינוי צריך לכתוב, וזה חלק מהעלות של מעבר לקוד. מה שאין על הלוח זו האפשרות.
- אותה לוגיקה מועתקת לחמישה מקומות. ברגע שתיקון אחד דורש חמישה עדכונים ידניים, ההעתקה תשבור לכם משהו במוקדם או במאוחר.
סימן אחד מתוך השלושה הוא לא סיבה לפרק מערכת עובדת. שניים ומעלה הם כבר תמחור של חוב שנצבר. חשוב לומר שרוב העסקים שאני פוגש לא מגיעים לשם בכלל, ומי שמגיע עושה זאת בחלק אחד של המערכת ולא בכולה.
הגישה שאני ממליץ עליה בפועל
כמעט תמיד מדובר בשילוב ולא בבחירה. הכלי הוויזואלי מחזיק את החיווט: מה מפעיל את התהליך, לאן זה הולך, מי מקבל התראה כשמשהו נופל. הקוד יושב בתוך התהליך ומטפל בחלק שקשה לצייר.
הסיבה פשוטה. החיווט משתנה הרבה ועדיף שיהיה גלוי לעין, והלוגיקה המסובכת משתנה מעט ועדיף שתהיה נבדקת. מי שמנסה לדחוף את הכל לצד אחד משלם על זה בצד השני.
אותו היגיון חל כשמוסיפים לתמונה מודל שפה. תהליך שרץ אותו דבר בכל פעם מתאים לאוטומציה, ומשימה שדורשת שיקול דעת מתאימה לסוכן. ההבחנה הזו קודמת לבחירת הכלי, לא נגזרת ממנה, ופירטתי אותה כאן.
שלוש שאלות שמכריעות את הבחירה
כשלקוח מבקש ממני להכריע בין השניים, אלה השאלות שאני שואל לפני שאני עונה:
- האם מידע רגיש עובר בתהליך. תשובה חיובית מטה מיד לכיוון הרצה עצמית, כלומר n8n.
- מי יתחזק את זה בעוד חצי שנה. אם התשובה היא אדם לא טכני בעסק, נוחות שווה יותר מגמישות.
- כמה יחידות חיוב הרצה אחת צורכת בפועל, וכמה פעמים ביום היא רצה. שני המספרים ביחד, ולא אחד מהם: יחידות להרצה נמדדות בהרצה אחת על נתונים אמיתיים, והחשבון החודשי הוא המכפלה שלהן בתדירות. הרצה שצורכת מעט וקורית כל דקה יקרה מהרצה כבדה שקורית פעם ביום, וכדאי לבדוק שתי הרצות ולא אחת כי הצריכה משתנה עם כמות הנתונים שנכנסת.
מי שרוצה להיכנס לרמת המפרט וההרשאות לפני שבונה, הפירוט המלא נמצא במדריך הבנייה. ומי ששואל את עצמו קודם אילו תהליכים בכלל שווים אוטומציה, ההתחלה הנכונה היא כאן.
שאלות ותשובות
מה זה n8n במשפט אחד?
כלי לבניית תהליכי אוטומציה על לוח ויזואלי: גוררים קופסאות, מחברים ביניהן, וכל קופסה מבצעת פעולה במערכת אחרת. ההבדל המרכזי מכלים דומים הוא שאפשר להריץ אותו על שרת שלכם ולא רק בענן של הספק, ושאפשר לשתול בתוכו קוד כשהלוח לא מספיק.
מה ההבדל בין n8n ל-Make?
שלושה הבדלים שמרגישים בפועל. הראשון הוא הרצה עצמית: את n8n אפשר להעמיד על שרת שלכם, את Make לא. השני הוא מודל התמחור, שנמדד בשתי יחידות שונות לגמרי ולכן שתי החשבוניות אינן ברות השוואה ישירה. השלישי הוא נוחות: Make קל יותר בהתחלה, n8n גמיש יותר כשהתהליך מסתבך.
האם צריך לדעת לתכנת כדי להשתמש ב-n8n?
לא כדי להתחיל. תהליך שמושך נתון ממערכת אחת ודוחף לשנייה נבנה בגרירה. ידע בתכנות הופך להיות רלוונטי בשלב השני, כשצריך לעבד מבנה נתונים לא צפוי או לכתוב תנאי מסובך, ואז יכולת שתילת הקוד היא מה שמונע מהפרויקט להיתקע.
כמה עולה n8n לעומת Make?
אי אפשר להשוות מחיר לחודש בלי לדעת כמה יחידות חיוב התהליך שלכם צורך, כי כל כלי סופר יחידה אחרת: Make מחייבת לפי אופרציות, ומודול מבצע אופרציה לכל חבילה שנכנסת אליו, כך ש-100 רשומות בחבילה אחת הן אופרציה אחת ואותן 100 רשומות אחרי איטרטור הן 100. n8n בחבילות המאוחסנות מחייבת לפי הרצה שלמה של תהליך, בלי קשר לכמות הרשומות בתוכה. לכן ספירת הצעדים על הלוח לא מספיקה. הדרך הנכונה היא להריץ תהליך אמיתי פעם אחת על נתונים אמיתיים, לקרוא כמה יחידות הוא צרך בפועל, להכפיל בתדירות ההרצה החודשית, ורק אז לפתוח את דפי התמחור ולוודא מול התנאים העדכניים. הרצה עצמית מוסיפה עלות שרת ותחזוקה שרוב ההשוואות באינטרנט שוכחות.
מתי עדיף לוותר על הכלי הוויזואלי ולכתוב קוד?
כשהתהליך כולל לוגיקה שקשה לצייר, כשצריך לבדוק אותו אוטומטית לפני כל שינוי, או כשמספר ההרצות הופך את החשבון לגדול מעלות פיתוח. בפועל רוב העסקים לא מגיעים לשם, וגם מי שמגיע עושה זאת בחלק אחד של המערכת ולא בכולה.
רוצים לדעת אם התהליך שלכם מתאים לכלי ויזואלי או לקוד?קבעו פגישת אבחון חינם ונעבור עליו יחד.