سلاح مهندسی مخفی Google Calendar: خویشتن‌داری

API ابتدایی آن زمان‌بندی را برای اینترنت امکان‌پذیر می‌سازد و کلاینت آن شاهکاری از خویشتن‌داری است.

نحوه عملکرد Google Calendar و آنچه ما به عنوان مهندس می‌توانیم از آن بیاموزیم.

معماری

---

فریمورک Frontend: هیچ‌کدام (!)‌. فقط چند کتابخانه داخلی برای مواردی مانند احراز هویت و ابزارهای مشترک.

استایل Frontend: نام‌های کلاس CSS، فراخوانی شده توسط JS.

ذخیره‌سازی Frontend: Cache Storage، IndexedDB (حالت آفلاین)، CDN (تصاویر و فونت‌ها).

ذخیره‌سازی API: Spanner DB.

APIهای خارجی: Google Meet، Google Contacts، Google Auth.

سرویس‌ها: heartbeat، eventing، notifications.

سایر: یک کامپایلر داخلی که دانلود و اجرای JS را سریع‌تر می‌کند.

مسائل جالب

---

البته، یک تقویم یک برنامه CRUD بزرگ است. اما اجازه ندهید این شما را فریب دهد - مسائل فنی چالش‌برانگیز زیادی وجود داشت که باید حل می‌شد.

API تقویم

• REST+JSON از سال 2011 (در ابتدا feed به سبک REST+RSS)
• مدل داده به شدت به رشته‌های تکرار iCalendar RFC 5545 متکی است (Microsoft و Apple از اشیاء اختصاصی استفاده می‌کنند)
• کلاینت‌ها می‌توانند مشاهده/اشتراک کنند تا هنگام تغییر رویدادها اعلان webhook دریافت کنند
• از همگام‌سازی‌های افزایشی برای سرعت پشتیبانی می‌کند... اما همچنین نیاز دارد که انقضا و همگام‌سازی مجدد را خودتان مدیریت کنید
• از سهمیه‌ها و محدودیت‌های نرخ برای کاهش مشکلات عملکرد استفاده می‌کند
• قدرتمند اما ابتدایی. آن‌ها به شما آنچه برای انجام هر کاری نیاز دارید می‌دهند، اما برای شما حل نمی‌کنند.

چیدمان HTML

بله، ساختاردهی HTML واقعاً می‌تواند جالب باشد! از آنجا که نماهای تقویم پر از محتوا هستند، اگر عناصر جداسازی نشوند، مشکلات عملکردی بزرگی رخ می‌دهد.

در اینجا مهم‌ترین لایه‌های HTML آمده است:

• شبکه: ردیف تمام روز، ستون‌های روز، رویدادهای زمان‌بندی شده، کانتینر
• رویداد پیش‌نمایش، که نمی‌تواند به یک ردیف/ستون قفل شود
• لایه کشیدن. این به شما اجازه می‌دهد وظایف را به شبکه DND کنید
• فرم‌ها: شناور در کنار رویدادها روی شبکه و گسترش یافته به یک دیالوگ تمام صفحه
• Toasts: برای پیام‌های تأیید

الگوریتم‌های Frontend

هر کلاینت تقویم چند الگوریتم جذاب دارد

• موقعیت رویداد: طول، ارتفاع و مختصات (X، Y) هر div رویداد. برای محاسبه این، باید مدت زمان رویداد و مقیاس نما را در نظر بگیرید.
• طول رویدادهای تمام روز: عرض و مختصات Y، که باید بر اساس رویدادهای اطراف تنظیم شوند.
• رویدادهای همپوشانی: نحوه تنظیم رویدادها هنگامی که زمان‌های مشترک دارند. پیاده‌سازی Gcal پیچیده‌تر از Outlook است (که هر رویداد را نصف می‌کند). شبه کد در زیر.

// overlapping events logic if start or end of targetEvent overlaps with any(events): if start and end of targetEvent = start and end of any(events): orderEventsAlphabeticallyByTitle() if start of targetEvent = start of any(events) and end != end of any(events): orderByDuration() //longest events go behind shorter events if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //events that start earlier go behind

\

مخزن Compass را برای پیاده‌سازی کامل این الگوریتم‌ها ببینید.

سرویس‌ها

این‌ها کارگران خارجی هستند که به کد کلاینت اجازه می‌دهند ساده و قابل اعتماد بماند

• سرویس Heartbeat — به GCal اجازه می‌دهد قابل اعتماد باشد و به آرامی به حالت آفلاین برگردد
• سرویس Eventing — رویدادهای به سبک pub/sub که webhookها را برای کلاینت‌ها تقویت می‌کنند. این به برنامه‌های دیگر اجازه می‌دهد بر روی API GCal بسازند.
• سرویس Notifications — هماهنگ‌سازی زمان‌بندی اعلان‌های قبل از رویداد شما. کلاینت می‌تواند این کار را به تنهایی انجام دهد، اما قابلیت اعتماد کمتری خواهد داشت.

[

\

نکات کلیدی

---

ساخت یک برنامه CRUD در مقیاس جهانی ممکن است از نمودار معماری ساده به نظر برسد، اما این سادگی هنوز نیاز به سطح بالایی از اجرا دارد.

• قابلیت اعتماد API: از آنجایی که بسیاری از برنامه‌ها به همگام‌سازی دو طرفه با GCal کاربر متکی هستند، API باید ساده، قابل گسترش و قابل اعتماد باشد. اگر اشتباه کنند، ارتشی از برنامه‌های دیگر را در پایین‌دست خراب می‌کنند.
• امنیت داده: داده‌های تقویم بسیار حساس هستند. آن‌ها به شدت به نقش‌های مبتنی بر scope متکی هستند تا اطمینان حاصل کنند که فقط افراد/برنامه‌هایی که شما مجوز داده‌اید می‌توانند به داده‌های شما دسترسی داشته باشند.
• سرویس‌های نظارتی: بررسی سلامت، ثبت وقایع و همگام‌سازی به طور مداوم در پشت صحنه در حال اتفاق است.

با توجه به نیازهای مقیاس، می‌توانید زندگی را برای خود آسان‌تر کنید با اینکه به سادگی کارهایی را انجام ندهید.

• نیازی نیست از استک رایج استفاده کنید. تصور کنید اگر آن‌ها همه چیز را رها کنند تا برنامه خود را در Angular بازنویسی کنند. سپس React. سپس Svelete. سپس NextJS. سپس HTMX. همه اینها پس از عرضه Google Calendar آمدند. GCal جاوا اسکریپت را انتخاب کرد، به سمت راست کشیده شد و دهه‌هاست با سرعت 64MPH در حال حرکت است. کسی اهمیت نمی‌دهد.
• نیازی نیست روی هر پلتفرمی منتشر کنید. اپلیکیشن دسکتاپ Google Calendar را همین الان باز کنید. منتظر می‌مانم.
• نیازی نیست با روندهای استایل همراه شوید. Bootstrap. Bulma. styled-components. Tailwind. نام‌های کلاس CSS.
• نیازی نیست بهترین UX را داشته باشید. حالت تاریک. فرم‌هایی که فضا را حفظ می‌کنند. حالت روشن #FFFFFF. فرم‌های تمام صفحه.
• نیازی نیست بهترین عملکرد را داشته باشید. امتیاز lighthouse آن‌ها در عملکرد 31/100 است.

بسیار شبیه به زندگی، هنگام عرضه محصول، شناخت خود سودمند است.

Google Calendar تلاش نمی‌کند برنامه مدرنی باشد که دستیاران اجرایی از آن برای برنامه‌ریزی 40 جلسه در روز استفاده می‌کنند (این همان چیزی است که Vimcal برای آن است).

Google Calendar هدف دارد برنامه ساده‌ای باشد که هر یک از 2 میلیارد کاربر آن بتواند بدون راهنمایی دستی آن را اجرا کند. امتیاز 88/100 در دسترسی‌پذیری دارد. UI تغییر نمی‌کند. از کار نمی‌افتد و اگر بیفتد، پشتیبانی آفلاین دارد.

فقط کار می‌کند.

این کافی است.

---

برای دریافت این بررسی‌های عمیق در صندوق ورودی خود، در خبرنامه من، Fullstack Engineer، مشترک شوید.

\