อาวุธลับทางวิศวกรรมของ Google Calendar: ความยับยั้งชั่งใจ

API ดั้งเดิมของมันช่วยให้สามารถจัดตารางเวลาสำหรับอินเทอร์เน็ตได้ และไคลเอนต์ของมันเป็นผลงานชิ้นเอกของความสำรวม

Google Calendar ทำงานอย่างไร และเราในฐานะวิศวกรสามารถเรียนรู้อะไรจากมันได้บ้าง

สถาปัตยกรรม

---

Frontend framework: ไม่มี (!) มีเพียงไลบรารีภายในองค์กรบางส่วนสำหรับสิ่งต่างๆ เช่น การยืนยันตัวตนและยูทิลิตี้ที่ใช้ร่วมกัน

Frontend Styling: CSS classnames เรียกใช้โดย JS

Frontend Storage: Cache Storage, IndexedDB (โหมดออฟไลน์), CDN (รูปภาพและฟอนต์)

API Storage: Spanner DB

External APIs: Google Meet, Google Contacts, Google Auth

Services: heartbeat, eventing, notifications

อื่นๆ: คอมไพเลอร์ภายในองค์กรที่ทำให้ JS ดาวน์โหลดและทำงานเร็วขึ้น

ปัญหาที่น่าสนใจ

---

แน่นอน ปฏิทินคือแอป CRUD ขนาดใหญ่แอปหนึ่ง แต่อย่าให้สิ่งนั้นหลอกคุณ — มีปัญหาทางเทคนิคที่ต้องการความพยายามมากมายที่ต้องได้รับการแก้ไข

Calendar API

• REST+JSON ตั้งแต่ปี 2011 (เดิมเป็น REST+RSS-style feed)
• โมเดลข้อมูล พึ่งพา RFC 5545 iCalendar recurrence strings เป็นอย่างมาก (Microsoft และ Apple ใช้อ็อบเจ็กต์ที่เป็นกรรมสิทธิ์)
• ไคลเอนต์สามารถ watch/subscribe เพื่อรับการแจ้งเตือน webhook เมื่อเหตุการณ์เปลี่ยนแปลง
• รองรับ incremental syncs เพื่อความเร็ว...แต่ยังต้องการให้คุณจัดการการหมดอายุและการซิงค์ซ้ำด้วยตัวเอง
• ใช้ โควต้าและอัตราจำกัด เพื่อลดปัญหาประสิทธิภาพ
• ทรงพลังแต่ดั้งเดิม พวกเขาจะให้สิ่งที่เพียงพอแก่คุณเพื่อทำสิ่งที่คุณต้องการ แต่พวกเขาจะไม่หาทางออกให้คุณ

HTML layout

ใช่ การจัดโครงสร้าง HTML อาจน่าสนใจจริงๆ! เนื่องจากมุมมองปฏิทินมีเนื้อหาที่หลากหลาย ปัญหาประสิทธิภาพขนาดใหญ่จะเกิดขึ้นหากองค์ประกอบไม่ถูกแยกออกจากกัน

นี่คือเลเยอร์ HTML ที่สำคัญที่สุด:

• กริด: แถวตลอดทั้งวัน, คอลัมน์วัน, เหตุการณ์ที่มีเวลา, คอนเทนเนอร์
• เหตุการณ์แสดงตัวอย่าง ซึ่งไม่สามารถล็อกไปที่แถว/คอลัมน์ได้
• เลเยอร์ลาก ช่วยให้คุณสามารถ DND งานไปยังกริดได้
• ฟอร์ม: ลอยอยู่ข้างๆ เหตุการณ์บนกริดและขยายเป็นไดอะล็อกแบบเต็มหน้าจอ
• Toasts: สำหรับข้อความยืนยัน

อัลกอริทึม Frontend

ไคลเอนต์ปฏิทินแต่ละตัวมีอัลกอริทึมที่น่าสนใจบางตัว

• ตำแหน่งเหตุการณ์: ความยาว, ความสูง และพิกัด (X, Y) ของแต่ละ event div ในการคำนวณนี้ คุณต้องคำนึงถึงระยะเวลาของเหตุการณ์และมาตราส่วนการแสดงผล
• ความยาวเหตุการณ์ตลอดทั้งวัน: ความกว้างและพิกัด Y ซึ่งต้องได้รับการปรับตามเหตุการณ์โดยรอบ
• เหตุการณ์ที่ทับซ้อนกัน: วิธีปรับเหตุการณ์เมื่อมีเวลาซ้ำกัน การใช้งานของ Gcal ซับซ้อนกว่าของ Outlook (ซึ่งแบ่งครึ่งแต่ละเหตุการณ์) Pseudo-code ด้านล่าง

// 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 repo สำหรับการใช้งานเต็มรูปแบบของอัลกอริทึมเหล่านี้

Services

เหล่านี้คือแรงงานภายนอกที่ช่วยให้โค้ดไคลเอนต์ยังคงเรียบง่ายและเชื่อถือได้

• Heartbeat service — ช่วยให้ GCal เชื่อถือได้และกลับไปสู่โหมดออฟไลน์อย่างเหมาะสม
• Eventing service — เหตุการณ์แบบ pub/sub ที่ขับเคลื่อน webhooks สำหรับไคลเอนต์ ช่วยให้แอปอื่นๆ สามารถสร้างบน GCal API ได้
• Notifications service — ประสานเวลาการแจ้งเตือนก่อนเหตุการณ์ของคุณ ไคลเอนต์สามารถทำสิ่งนี้ได้เองตามทฤษฎี แต่จะเชื่อถือได้น้อยกว่า

[

\

สิ่งที่ได้เรียนรู้

---

การสร้างแอป CRUD ในระดับโลกอาจดูตรงไปตรงมาจากแผนผังสถาปัตยกรรม แต่ความเรียบง่ายนั้นยังต้องการระดับการดำเนินการที่สูง

• ความน่าเชื่อถือของ API: เนื่องจากแอปจำนวนมากพึ่งพาการซิงค์สองทางกับ GCal ของผู้ใช้ API จึงต้องเรียบง่าย ขยายได้ และเชื่อถือได้ หากพวกเขาทำผิดพลาด พวกเขาจะทำลายแอปอื่นๆ มากมายที่อยู่ด้านล่าง
• ความปลอดภัยของข้อมูล: ข้อมูลปฏิทินมีความละเอียดอ่อนอย่างยิ่ง พวกเขาพึ่งพาบทบาทตามขอบเขตเป็นอย่างมากเพื่อให้แน่ใจว่ามีเพียงคน/แอปที่คุณอนุญาตเท่านั้นที่สามารถเข้าถึงข้อมูลของคุณได้
• บริการตรวจสอบ: การตรวจสอบสุขภาพ, การบันทึก และการซิงค์กำลังเกิดขึ้นอย่างไม่หยุดหย่อนเบื้องหลัง

เมื่อพิจารณาจากความต้องการในระดับ คุณสามารถทำให้ชีวิตง่ายขึ้นโดยเพียงแค่ ไม่ทำบางสิ่ง

• คุณไม่จำเป็นต้องใช้สแต็กที่กำลังเป็นที่นิยม ลองจินตนาการว่าหากพวกเขาทิ้งทุกอย่างเพื่อเขียนแอปใหม่ใน Angular แล้ว React แล้ว Svelete แล้ว NextJS แล้ว HTMX ทั้งหมดนั้นมาหลังจาก Google Calendar เปิดตัว GCal เลือก JS แล้วไปช่องขวาและแล่นที่ 64 ไมล์ต่อชั่วโมงมานานหลายทศวรรษ ไม่มีใครสนใจ
• คุณไม่จำเป็นต้องเผยแพร่บนทุกแพลตฟอร์ม เปิดแอป Google Calendar บนเดสก์ท็อปตอนนี้เลย ฉันจะรอ
• คุณไม่จำเป็นต้องตามทันเทรนด์การจัดสไตล์ Bootstrap. Bulma. styled-components. Tailwind. CSS class names.
• คุณไม่จำเป็นต้องมี UX ที่ดีที่สุด โหมดมืด ฟอร์มที่ประหยัดพื้นที่ #FFFFFF โหมดสว่าง ฟอร์มเต็มหน้า
• คุณไม่จำเป็นต้องมีประสิทธิภาพที่ดีที่สุด คะแนน lighthouse ของพวกเขาในด้าน Performance คือ 31/100

เช่นเดียวกับในชีวิต การรู้จักตัวเองจะคุ้มค่าเมื่อส่งมอบผลิตภัณฑ์

Google Calendar ไม่ได้พยายามเป็นแอปสมัยใหม่ที่ผู้ช่วยผู้บริหารใช้จัดตารางประชุม 40 ครั้งต่อวัน (นั่นคือสิ่งที่ Vimcal มีไว้สำหรับ)

Google Calendar มีเป้าหมายเป็นแอปง่ายๆ ที่ผู้ใช้ 2 พันล้านคนสามารถใช้งานได้โดยไม่ต้องมีคนช่วยเหลือ มันได้คะแนน 88/100 ในด้านการเข้าถึง UI ไม่เปลี่ยนแปลง ไม่ล่ม และมีการรองรับออฟไลน์หากมันล่ม

มันใช้งานได้

นั่นเพียงพอแล้ว

---

หากต้องการรับการเจาะลึกเหล่านี้ในกล่องจดหมายของคุณ สมัครรับจดหมายข่าวของฉัน Fullstack Engineer

\