לא פעם פונים אלינו בשאלה לגבי קונקטור כזה או אחר בטאבלו. מצורף הסבר מדוע לא נכון לכתוב לוגיקות עסקיות בכלי ה-Front.
לא פעם אנחנו מקבלים פניות ושאלות לגבי אפשרות חיבור מוצר כזה או אחר לטאבלו. ממשיקים כמו Google Ads, Facebook Ads, Google analytics, Sales force ועוד. עבור אנשי BI ודאטה זו צריכה להיות נורה אדומה צועקת.
נכון, טאבלו יודע להתחבר למגוון רחב של מקורות מידע, זה בהחלט יכול לתת מענה לאנליסט בארגון שרוצה רק למשוך טבלה כזו או אחרת כדי לראות את המידע. אבל אם התפקיד שלכם הוא לספק דוחות לארגון, אתם ממש לא רוצים לבנות את הלוגיקה העסקית שלכם בכלי ה-BI. זה נכון לכל כלי, Google Data Studio, Qlik ואחרים. לא מעט ארגונים עושים את הטעות הזו ומגיעים אלינו לאחר מעשה כדי ש״נתקן״ ונעזור להם לצאת מהברוך. הגישה שלנו בתחום היא לא אולי, או לפעמים, הגישה חד משמעית, אינטגרציה של נתונים עושים בבסיס נתונים. זה לא אומר שצריך עכשיו מודל שלם של Data warehouse בשביל חיבור של שני מקורות. אבל זה כן אומר שיש לדאוג לסנכרון בין אותו מקור נתונים לבין בסיס הנתונים. ולצורך זה משתמשים בכלי אינטגרציה. כלים כמו Rivery.io בנויים בדיוק לצורך הזה, יודעים למשוך את המידע מכל API אפשרי ויותר חשוב, יודעים להריץ עיבוד נתונים והכנה שלהם למבנה המתאים לכלי הדוחות. להבדיל הלוגיקה שתוכלו לעשות בכלי הפרונט תהיה הרבה יותר מוגבלת. ראו למשל את הפוסט המעניין הזה שמסביר דוגמא לתחקור נתונים מ-Facebook Ads, זו לוגיקה שלא ניתנת למימוש בכלי פרונט (ראו פוסט)
סיבה לא פחות חשובה למדוע לא לעשות לוגיקה בכלי פרונט היא שאתם כובלים את עצמכם לכלי איתו אתם עובדים. ומה אם מחר משתמש אחר בארגון ירצה להתחבר לנתונים באמצעות Python, Jupiter או אפילו אקסל? או אחת המערכות שתרצה לפנות לנתונים בצורה מתוזמנת לצורך קבלת החלטות. במקרים כאלה מהר מאד תמצאו את עצמכם משכפלים את הלוגיקה. לעומת זאת, העיבוד שתעשו בבסיס הנתונים הוא נכס שמקדם את הארגון להבדיל מחיבורים זמניים בכלי הדוחות שככל הנראה תצטרכו לשכתב ברגע שהמודל נתונים טיפה יסתבך וזה לרוב קורה הרבה יותר מהר ממה שאתם חושבים.
コメント