ב אני מברך את גוגל על כך שהיא אמרה "לא" ללא התנצלות לניסיונות המודרניים. כלי ההנדסה הסודי של לוח השנה של Google: מגבלות תודה על הקריאה טכנאי מלא! להירשם בחינם לקבל הודעות חדשות ותמיכה בעבודתי. חתימה "Use a frontend framework." No. JavaScript. "Use Typescript." No. Javascript. "Use a trendy CSS tool." No. CSS classnames. "Give us a native desktop app." No. Browser. "Give us dark mode." No. "Make it really fast." No. מחויבותם לפשטות סייעה ל-GCal להגן על מעמדה כמועדון ברירת המחדל עבור מיליארדי אנשים רגילים. עבור לקוחות API, עם זאת, אותה הפשטות עושה את החיים מסובכים באופן טרגי. איך המורכבות הזאת מתגלגלת, ומה אנחנו יכולים ללמוד ממנה כבניינים. הבעיה: שמירה על נתונים בסינכרון אתה בונה לוח שנה חדש מגניב בשם לוח שנה מגניב. כדי לעזור למשתמשים להתחיל, אתה מאפשר להם לייבא את לוח השנה הקיים שלהם ב- Google. הדבר ידרש גישה לנתוני לוח השנה של Google של המשתמשים שלך. אתה מסתכל על API GCal ורואה את החשודים הרגילים: “חמוד,” אתה חושב. ”אני רק צריך לקבל את , ולאחר מכן קבל את כל האירועים עבור לוח שנה זה.כאשר אני צריך לעדכן אירוע, אשתמש מתוך GET התשובה » calendarId eventId events אתה יכול לעשות את כל זה עם כמה פונקציות פשוטות: כל האירועים נמצאים ב- DB שלך, והם מופיעים גם ב- GCal של המשתמש לאחר שמשתמש מעודכן אירוע מ- UI שלך. אתה פותח את האפליקציה GCal, ליצור אירוע חדש בשם "Celebrate at Denny's", ומצפה לפנקייקים שלך ציפורן רוול. האפליקציה Cool Cal פתוחה, אבל האירוע החדש לא מופיע. הבטן הריקה שלך יורדת כאשר אתה מבין שאתה רק מיושם חצי הפתרון (CoolCal → GCal). אתה עדיין צריך לוודא כי שינויים GCal להפיץ לוח שנה מגניב (GCal → CoolCal). הכחשה אתם יודעים שאחרים נתקלו במקרה זה בעבר, אז אתם מבקרים מחדש את מסמכי API של GCal. למרבה המזל, אתה מוצא מדריך בשם " » » סינכרון משאבים ביעילות המדריך הוא קצר, מה שהופך אותך בקלות. נראה שאתה רק צריך להוסיף כמה שיחות נוספות. מכיוון שאתה לא יודע כמה אירועים היו מעודכנים או מתי הם היו, אתה יודע שאתה צריך מעגל כדי לאסוף את כולם. זה הגיוני למרבה המזל, המסמכים כוללים קטע מלא של זה ב-Java. הוא אפילו משתמש ב אסטרטגיה שגורמת לכם להרגיש חכמים. do-while אתה יכול פשוט להמיר את זה ל- JavaScript ולהמשיך הלאה. כעס זה עבר שעה, ואתה הפך בהצלחה את החתימה לתכונה בשם JavaScript. עדכנו את האש שלכם syncGcal() זה עובד ! בכל פעם שאתה רץ , נתוני GCal החדשים של המשתמש מוסיפים CoolCal. syncGcal() אתה מחליט לכלול את עוגת הגבינה בסגנון ניו יורק עבור הבעיות שלך. כשאתה בדרך החוצה, כמה שאלות מתעוררות במוח העייף שלך... ה-SyncToken אינו מתמשך בשום מקום syncGcal() פועל רק כאשר הוא נקרא באופן ידני How often should I run syncGcal() ? כל שעה ? כל דקה ? Where will I store the token? מחסן מקומי ? The את האוסף? user אוסף חדש ? What happens if the token becomes invalid? האם אני יכול להמשיך לחזור? האם אני צריך לבצע ייבוא מלא כקופסת גיבוי? מה לגבי גבולות הקוונים? מה אם משתמש עושה שינוי במהלך תהליך זה? אתה כועס – על המנחה שלא הזהיר אותך על מקרים אלה, ואז על הנאיביות שלך להניח שזה צריך להיות. עסקאות "אני לא לבד - אני יכול להגיע לעזרה", אתה אומר לעצמך, בדיוק כמו שאתה מתאמן בטיפול. אתה בטוח כי מסמכי ה- API יהיו שיטה בשם מה שאתה מתעלם. syncResources() כמו חברה מסוימת של YC שתסנכרן קסם את כל הנתונים שלך בשבילך. לפחות, יהיה תלמיד של ריצ'רד סטאלמן שיש לו רפאו של MIT שאתה יכול להדגיש את קלוד. > clone the two-way sync stuff from github.com/stallman-cal. no bugs. דיכאון המסמכים הרשמיים הם רק. כל חברות YC הן סוכני בנייה. סטאלמן אינו סומך על אפליקציית לוח השנה שלך למטרות רווח. (יש פרוייקט שנקרא אבל יש לו רק 200 כוכבים, אי אפשר לסמוך עליו.) לוח זמנים Compass אף אחד לא דואג לתכונה הסינכרון השנייה שלך. אתה בעצם לבד. דמעה אחת נופלת על המקלדת המכנית שלך כשאתה מבין שאתה לא הולך לדני היום. קבלה לאחר טוסט צרפתי ביתי וטיול אחרי הארוחה, אתה מגיע להסכמה עם הגורל שלך לפעול כמו מהנדס אמיתי ולעשות את זה בעצמך. כמה שבועות לאחר מכן, זה סוף סוף נגמר. אבל אתה עדיין לא יכול להפסיק לשאול "למה ג'יימס עשה את זה ככה? "האם זה היה צריך להיות כל כך מסובך?" הדרישות אתה מטיל את עצמך בנעליים של Google על ידי ההנדסה הפוכה של הדרישות בצורה של (באמצעות PRD דרישות המוצר Doc הפתרון זה היה כיף, אז אתה מסמך את הפתרון כדי לענות על הדרישות האלה כמו • TDD עיצוב טכני Doc ניתוח לבסוף, אתה מרגיש מוסמך לומר אם הפתרון של GCal "תנו להם טוקן" היה טוב. היתרונות של Token Pagination הם מסוגלים להסתיר את המורכבות מהלקוח, כך שהם לא צריכים להבין הכל (לדוגמה, רב-אזור רבייה) Opaque tokens protect the client from overwhelm. על ידי בקרת מתי טוקינים נופלים, GCal יכול להבטיח כי הלקוחות תמיד רואים מחיקות במהלך הסינכרון המשך. Cleanly handles deletions. Google יכול לשנות לחלוטין את אחסון האחסון שלה, אסטרטגיה sharding, או טופולוגיה מבלי להשפיע על הלקוחות. ) Easier implementation changes. תגיות highscalability.com חולשות ה-webhook אומר לך משהו השתנה, אבל לא מה.זה אומר שכל הודעה דחופה מפעילה שיחת סינכרון מתקדמת חדשה.זה הופך לשוחח כאשר משתמשי הכוח מבצעים התאמות תכופות.למה לא לכלול diff קל בשפע משקל דחוף עצמו, או לפחות לציין אילו ID אירועים השתנו? Push is disconnected from sync. סינכרון מוגבר אינו תואם את ו אתה חייב לבחור שיטה אחת או את השנייה.זו בעיה עבור בני אדם, שחושבים במונחים של זמן בקלות יותר מאשר בטוקינים. Some filters are incompatible timeMin timeMax טוקי הדף הם אפשריים. אם לקוח נופל באמצע הדף (אחרי עמוד 3 של 7), הם חייבים להפעיל מחדש את הסינכרון כולו. עבור לוח שנה גדולים, זה כואב. חלופה תהיה טוקי הדף קבועים אשר לשרוד בין הפגישות, או בדיקת התקדמות הסינכרון. No partial sync recovery. חלופות (ולמה לא השתמשו בהן) קו התחתון הגישה Sync Token + Cursor Pagination היא זהו אותו דפוס המשמש על ידי Microsoft Graph (טוקי דלטה), Stripe (עמודים דפים), ורוב API הארגוניים. pragmatic, battle-tested pattern Google בחרה בו כי זה מאפשר להם להסתיר את המורכבות הפנימית תוך מתן "טוב מספיק" סינכרטיקה עבור 99% של מקרים של שימוש בלוח השנה. האפשרויות החלופיות (הזנת אירועים, CRDTs, OT) יהיו הגיוניות רק אם GCal דורש שיתוף פעולה בזמן אמת או סינכרון P2P מקוון אמיתי. התמונה המלאה אם המטרה של Google עם GCal הייתה להרוויח הכנסה, הם היו מציעים יותר מסמכים, קטעי וידאו וסדנאות אינטרנט. npm i gcal אבל המטרה של Google עם GCal היא פחות שאפתנית: >> Don’t annoy regular users so much that they download Apple Calendar. זה לא הוגן לצפות כל כך הרבה מן API בחינם. זה מדהים שאתה יכול לשלב עם GCal במקום הראשון GCal מכבדת את האחריות שלה כחלק בסיסי של האפליקציה שלך על ידי עדיפות אמינות על הנוחות של אימוץ: לא הרבה כישלונות קורים. ה-API עושה מה שהדוקטורים שלו אומרים, גם אם הם לא אומרים הרבה. הם לא מפתיעים אותך עם שינויים שבורים עדיין , כאשר הם חושבים לראשונה, "אני יודע, אני רק אשלב עם GCal." there is a gap between the developer’s expectations and reality כיום, המפתחים צריכים לסגור את הפער הזה עם זמן, מאמץ ואובדן של חף מפשע. אבל Google יכולה להפחית את הכאב על ידי מתן יותר משאבים. לדוגמה, המסמכים יכולים לספק הוראות יישום נוספות. דוגמאות הקוד יכולות להתפתח מ- bare repos ליישומים דמויי. על האיזון, שמירה על API פשוט היה הצעד הנכון. API פרימיטיבי יכול להטריד את משתמשי החשמל. אבל אם זה לא משפיע על UX, הכנסה, שמירה, או המותג, אז לשמור על זה פשוט. Takeaways עבור בונים בעת יצירת API סינכרון ציבורי Keep it boring: use existing standards ראינו כאן כיצד ה- API של GCal בנוי על פיג'ינג וסינכרון סינכרון.המודל האירועים שלו בנוי גם סביב סטנדרטים שנקבעו: CalDAV, iCalendar ו-RRULEs. במקום להמציא את גירסאות האופטימיזציה שלהם, הם התעקשו על היסודות.זהו סיבה גדולה מדוע היו כל כך הרבה שילובים מוצלחים של GCal מאז ה- API שלהם הפך לפומבי בשנת 2006 (בניגוד ל- Yahoo). Use cursor pagination when the data is a moving target כאשר כתובים מתרחשים בזמן שאתה קורא, אתה צריך עקביות בכל העמודים כדי למנוע כפולים ושורות אבודות. דוגמאות: לוח שנה, זרמים, יומני ביקורת, זרמים רק בתוספת. Use offset pagination when the data is stable אם הנתונים סטטיים ואין להם כתבות מקבילות, אתה יכול להיפטר עם גישה פשוטה יותר. דוגמה: תוצאות חיפוש עם מספרים של עמודים, טבלה מנהל עבור נתונים קטנים. Don’t oversell the API אתם יודעים איך זה מרגיש להתלהב בבוקר כדי לסיים יחסי ציבור ולאחר מכן לטייל ... רק כדי להבין שזה יותר מסובך ממה שחשבתם ולא לראות את אור היום עד אחר הצהריים הבא. API של Google לא מבטיח לעשות הכל בשבילך. המוצר הסופי ימכור את ה-API: לבלות את הזמן שלך לשמח את המשתמשים שלך עם המוצר שלך לפני לדאוג לשמח את המפתחים המשלבים אותו. Don’t break things אם השילוב שלך הוא בסיסי למוצר של מישהו אחר, אז ללכת לאט. לבלות יותר זמן בדיקת ההגירה. קבל משוב על המסמכים לפני הפעלתם אותם. שלח הודעות דואר אלקטרוני ו-Terminal כך שאף אחד לא יהיה מופתע. זה דורש שינוי זהות מ"קודר Vibe Crackhead" אשר שובר דברים ב-PROD ל"הנדס תוכנה משמעת". אתה לא תמיד מקבל את זה נכון, אבל לקחת את האחריות ברצינות. שינוי אחד יעשה יותר נזק מאשר שלושה תכונות יעשו טוב. API של GCal הוא יציב, אז ציון השינה שלי למרבה המזל לא ירד מאז השימוש בו. בעת שילוב API סינכרון ציבורי Don’t start with an integration "אבל המשתמשים שלי לא ישתמשו ביישום שלי אלא אם כן הוא משולב עם הכלים שהם כבר משתמשים בהם". "אבל המשתמשים שלי לא ישתמשו ביישום שלי אלא אם כן הוא משולב עם הכלים שהם כבר משתמשים בהם". אולי, אבל תן להם לומר לך את זה. הוספת אינטגרציה היא משימת צד יקר על המסע המותאם לשוק המוצר שלך. אם תרומת הערך טובה מספיק, לא תהיה להם בעיה ליצור חשבון חדש ולהוסיף נתונים מההתחלה. Accept that Pareto is right במילים אחרות, 20% האחרונים של המשימות ייקחו 80% מהזמן. פני השטח עבור מקרים קצוות וגוטצ'ה מתרחב ככל שאתה מיישם. המסמכים של Google אינם היחידים שיפתרו אותך לחשוב שהדברים יכולים להיות פשוטים וחופשיים. להגביל את הבטחותיהם על ידי חישוב מחזורים, idempotency, fallback, delta syncs, offline, ביטול טוקן, קוויות, בקשות תנאי (ETags). אתה לא צריך את כל אלה עבור MVP שלך, אבל מצפה שהם יגיעו בסופו של דבר. Simplicity for one party means complexity for another תגית: Complex Backend טוב למשתמשים רגילים → קשה למשתמשים חשמליים מחירים פשוטים → R&D מורכב API פשוט → אינטגרציה מורכבת בפעם הבאה שאתם חושבים, "אני פשוט אשתמש ב-API החינמי הזה, זה נראה פשוט", זכור: It’s either free or simple; Someone always pays. אז בואו לקחת את העוגיות שלכם.
