JSON давно стал чем-то вроде «родного формата интернета»: читается глазами, бьётся в консоль, понимается любым фреймворком. Он прост, дружелюбен и узнаваем — как HTTP или HTML.
Но опытный разработчик Alois Deniel спустя годы практики сделал вывод, который многим покажется крамольным: JSON стал тормозом, а Protobuf — вполне зрелой заменой, которую мы недооцениваем.
Его статья — это не религиозный спор, а честное признание проблемы: удобный формат перестал быть оптимальным. И многие архитектуры платят за это временем, трафиком, типовыми ошибками и болью от валидации.
⚙️ Почему JSON перестал справляться
Alois описывает опыт, знакомый каждому, кто в продакшене трогал чужие API:
- 🧩 отсутствующие или лишние поля
- 🔠 строки вместо чисел и наоборот
- 🐛 тихие ошибки парсинга
- 🧾 беспорядочная эволюция контрактов
JSON хорош в прототипах. Но в долгоживущих системах он превращается в минное поле: каждый новый клиент приносит свою интерпретацию. Бэкенд усложняется. API покрывается обвязками, валидацией, проверками и тестами, которые должны компенсировать слабую типизацию.
С Protobuf это всё исчезает — и это ключевой аргумент.
🔥 Protobuf работает там, где JSON сдаётся
Protobuf — это не просто «другой формат». Это контракт, которому обязаны следовать все стороны.
🧱 1) Схема как закон
Файл .proto — это строгий описатель структуры.
Ты не можешь «случайно» отправить не тот тип или пропустить поле.
Это делает API:
- 💡 самодокументируемым
- 🧪 тестируемым
- 👮 защищённым от человеческих ошибок
🧬 2) Автогенерация кода
Один .proto → десятки языков.
Хочешь Dart?
Хочешь Go?
Хочешь Swift?
Хочешь Rust?
Все получают одинаковые, строго типизированные структуры — и риск «разъезда схемы» исчезает.
⚡ 3) Бинарный формат в 3× компактнее
Когда JSON отправляет:
{
"id": 42,
"name": "Alice"
}
Protobuf отправляет только значения и номера полей.
И экономит трафик, CPU и время десериализации.
Результат:
- 📉 меньше задержка (latency)
- 📦 меньше трафика
- 📱 меньше расхода мобильных данных
- 🚀 быстрее отклики API
Это особенно заметно в мобильных, IoT и real-time-сервисах.
🛠 Пример: за минуту — HTTP-сервер на Protobuf
Alois показал код на Dart, где:
- сервер отвечает бинарным Protobuf-пакетом,
- клиент его принимает и десериализует,
- никакой ручной проверки типов.
Весь смысл в такой строчке:
final user = User.fromBuffer(response.bodyBytes);
Никакого jsonDecode(), никаких try/catch, никакого риска пропустить поле.
Типы и структура — уже гарантированы.
Protobuf становится частью архитектуры, а не просто заменой JSON.
🔍 Но есть один минус… и он реальный
JSON можно открыть чем угодно:
- браузером
- Notepad
- телом запроса в Postman
- console.log
Protobuf — бинарный.
Без схемы он — просто набор байт:
1: 42
2: "Alice"
Это означает:
- 🧰 нужно держать схему под рукой
- 🧪 нужны инструменты для декодирования
- 📚 нужна культурная дисциплина версионирования контрактов
Но этот «минус» — просто цена взрослого подхода.
Как только проект становится сложным, человекочитаемость перестаёт быть аргументом.
Как никто не пишет базы данных в CSV, так и API не обязано оставаться текстовым.
💭 Моё мнение: JSON останется, но его эпоха универсальности закончилась
Я не считаю, что JSON должен исчезнуть.
Но я убеждён, что в высоконагруженных системах Protobuf — это уже новый стандарт качества.
Почему?
✨ 1. API больше похожи на контракты, чем на документы
И Protobuf идеально описывает этот подход.
🚀 2. Производительность становится ключевой в мире real-time
Стриминг, push-уведомления, графы, игры, мобильные приложения —
просто не могут себе позволить JSON-овский overhead.
🧠 3. Автоматизация выигрывает у гибкости
Меньше ручной валидации → меньше багов → меньше QA
Это путь к настоящему DX (developer experience).
🌐 4. gRPC, microservices, event-driven архитектуры — все уже живут в Protobuf-мире
И публичные API в скором времени подтянутся.
🏁 Итог
Alois прав в одном:
JSON стал стандартом не потому, что он лучший, а потому, что он удобный.
Но в зрелых системах удобство перестаёт быть достаточным аргументом.
И Protobuf предлагает:
- 🚀 скорость
- 🧱 надёжность
- 🎯 строгие контракты
- ⚙️ автогенерацию
- 📦 компактность
И если ты строишь будущее API, а не учебный пример — Protobuf станет не просто заменой, а инженерным преимуществом.