Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 Контент вільний від AI. Цей пост на 100% написаний людиною, як і все на моєму блозі. Насолоджуйтесь!

27.11.2023

JSON - універсальний формат даних для всіх випадків

Для серіалізації структур даних у рядок є одне правильне рішення: JSON. Є кілька випадків, коли це не найкращий вибір, а у всіх інших можна два рази не думати. (Раніше писав про HTTP/JSON).

• Для документів, що призначені для редагування людьми. Синтаксис JSON надлишковий; чого варти тільки обовʼязкові лапки навколо ключів. Також немає стандартної підтримки коментарів — життєво необхідної для документів функції. Зате є інше певне рішення: YAML. (Чи знаєте ви, що стандарт YAML є надбудовою над JSON?)

• Для двійкових даних. В JSON їх доведеться кодувати — скоріше за все в Base64. Це зайві витрати як по розміру (хоча Base64 чудово стискається в GZip), так і по часу (а якщо стискати — то ще більше.) На великому масштабі має сенс тримати двійкові дані окремо. З файлами досить поширено явище sidecar file. У HTTP, звісно, є multipart. В базах даних — поля blob.

• Для “високонавантажених” вузлів варто переходити до форматів, де структура задається окремо - Protobuf або Cap’n’Proto. А для масивів даних - Parquet. Обовʼязково треба памʼятати, що відокремлення схеми робить дані менш прозорими та ускладнює підтримку. Тому “високу навантаженість” треба починати надзвичайно високо. Якщо сервіс всередині робить виклики AWS SDK по HTTP/JSON, то навряд чи йому потрібна gRPC. А для зберігання масиви JSON, стиснуті у GZip, практично не додають зайвого розміру, оскільки GZip чудово стискає повторювані рядки, якими є ключі та розмітка JSON.

Серед переваг JSON - легкість в розумінні людиною, висока архівна якість, наявність якісних, ретельно оптимізованих та перевірених (це дуже важливо!) бібліотек для будь-якого середовища. В роботі багато дилем, але для серіалізації можна спокійно брати JSON.