העלאת קבצים גדולים בלי להפיל את השרת

הדרך הטבעית לבנות העלאת קובץ היא גם הדרך שנשברת ראשונה: הדפדפן שולח את הקובץ לשרת שלכם, השרת מקבל אותו לזיכרון, ואז מעביר אותו לאחסון. זה עובד מצוין עד שמישהו מעלה קובץ אמיתי.

הבעיה היא לא רוחב הפס. הבעיה היא שלפלטפורמות יש תקרה על גודל הבקשה, והתקרה הזאת נמוכה בהרבה ממה שנראה סביר.

באתר הזה, למשל, העלאת תמונה למאמר עוברת דרך Route Handler ולא דרך Server Action. הסיבה יחסית משעממת אבל מאוד מעשית: ל-Server Actions ב-Next יש מגבלה של מגהבייט אחד על גוף הבקשה, והיא זורקת שגיאה 413 מעליו. גם אחרי שמרימים את המגבלה, ל-Vercel עצמה יש תקרה של בערך 4.5 מגה. כלומר יש שתי תקרות, אחת מעל השנייה, ורק אחת מהן בשליטתכם.

מי צריך להחזיק את הקובץ

בפרויקט Fingerprint המשתמשים מעלים חבילות של קבצי תלת-מימד, וזה לא 4 מגה. הארכיטקטורה שם מוציאה את השרת מהנתיב של הקובץ לגמרי.

השרת מייצר כתובת חתומה וזמנית מול האחסון (Cloudflare R2, דרך @aws-sdk/client-s3 ו-s3-request-presigner), מחזיר אותה לדפדפן, והדפדפן מעלה את הקובץ ישירות לאחסון. השרת לא ראה אף בייט. מה שהוא כן עשה זה להחליט מי מורשה להעלות, לאן, ולכמה זמן הכתובת תקפה.

ההבחנה הזאת שווה משפט משלה: תפקיד השרת הוא לתת רשות, לא לסחוב בייטים.

לצמצם לפני שמעלים

ב-Fingerprint הקבצים נארזים לארכיון בצד הלקוח, עם JSZip, לפני שהם יוצאים מהדפדפן. זה נשמע כמו פרט קטן וזה שני דברים בבת אחת: פחות בייטים על הרשת, והעלאה אחת במקום עשרים בקשות נפרדות שכל אחת יכולה להיכשל בנפרד.

גם באתר הזה יש גרסה קטנה של אותו רעיון. תמונה שמועלית לניהול התוכן עוברת קידוד מחדש ל-WebP באיכות 78 לפני שהיא נשמרת, כך שצילום מהטלפון נכנס במשקל של תמונה שנוצרה מראש ולא במשקל המקורי שלו.

מה שנשאר לשרת לעשות

אחרי שהקובץ לא עובר דרככם, נשארות שלוש החלטות שאי אפשר להעביר לדפדפן, כי הדפדפן הוא לא מקור אמת:

• מי מורשה להעלות, ולאיזה נתיב. הכתובת החתומה נוצרת בשרת אחרי שהבדיקה עברה, לא לפניה.
• מה מותר להעלות. סוג הקובץ וגודלו נבדקים בצד השרת גם אם הדפדפן כבר בדק, כי בדיקה בדפדפן היא נוחות למשתמש ולא אכיפה.
• מה קורה אחרי. שהקובץ באחסון זה לא אומר שהמערכת יודעת עליו. צריך רשומה במסד הנתונים שנכתבת בשרת, אחרת יש לכם קבצים שאף אחד לא יכול למצוא.

הנקודה השלישית היא זו שנשכחת. קל לבדוק שההעלאה עבדה וקשה לגלות חודש אחר כך שחצי מהקבצים באחסון לא מקושרים לשום דבר.

לבדוק את זה מראש, לא בהשקה

לפני שבונים: מה התקרה של הפלטפורמה שאתם עליה, ומה הקובץ הגדול ביותר שמשתמש באמת ינסה להעלות. אם המספר השני גדול מהראשון, ההחלטה הארכיטקטונית כבר נקבעה בשבילכם, ועדיף לדעת את זה ביום הראשון.

הרעיון שהדפדפן הוא תצוגה ולא מקור אמת חוזר גם בתשלומים — כתבנו עליו בחיבור תשלום באתר לחשבונית ירוקה.

מערכת שמעלה, שומרת ומנהלת קבצים כמו שצריך