Hacker News Digest

URL может быть не просто адресом страницы, а полноценным хранилищем состояния веб-приложения. Автор статьи случайно обнаружил это, когда в коде PrismJS нашёл URL, который полностью восстанавливал его конфигурацию подсветки синтаксиса — все темы, языки и плагины были закодированы в одном адресе. Это напомнило ему о мощи URL как инструмента управления состоянием, который часто игнорируют в пользу сложных решений вроде глобальных хранилищ и контекстов.

URL предоставляет четыре ключевых преимущества бесплатно: возможность делиться ссылками, создавать закладки, использовать историю браузера и глубокую навигацию. Разные части URL кодируют различные типы состояния: путь — для иерархической навигации, параметры запроса — для фильтров и настроек, якоря — для клиентской навигации. Среди распространённых паттернов для параметров запроса — множественные значения через разделители, вложенные данные, булевы флаги и массивы.

• Обсуждение охватывает вопросы: стоит ли хранить состояние в URL, какие ограничения накладывает это, какие есть альтернативы и какие есть подводные камни (отсутствие семантики, безопасность, длинные URL-ы и т.д.).
• Участники обмениваются опытом, что иногда приводит к тому, что URL становится слишком длинным, что это может вызвать проблемы.
• Обсуждается, что такое состояние должно быть сериализуемо так, чтобы его можно было закодировать в URL, и что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.
• Разговор затрагивает, что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.
• Участники обсуждают, что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.

Почему Protobuf плохи

Protobuf — это любительская, непродуманная технология, созданная для задачи, которую в действительности имеет только Google. Их главная беда — убогая типовая система: нет композиции, куча произвольных запретов (oneof нельзя повторять, map нельзя параметризовать, ключ map не может быть bytes или enum и т.д.). Всё это — следствие донавешивания фич «как получится» вместо проектирования.

Достаточно трёх простых конструкций: обязательные поля (произведение типов), oneof как отдельная копроизводная и параметрические типы. На них можно выразить optional, repeated, map без всяких хаков.

Ещё protobuf разделяет «скаляры» и «сообщения». Скалярные поля всегда «есть»: даже если ты их не заполнял, они инициализируются нулём/пустой строкой. Отличить «поле не прислали» от «прислали 0» невозможно — источник багов и лишних костылей.

• Критика protobuf сводится к «плохо, но альтернатив ещё хуже»: ни одна другая схема не даёт таких же гарантий обратной совместимости + встроенный линтер.
• Главные боли: нулевые значения неотличимы от «не установлено», нет композиции/алгебраических типов, oneof и repeated ограничены, инструментарий (protoc) громоздок.
• Часть проблем — культурное наследие Google: «не давать пользователю обобщений, зато добавить 100 специальных случаев».
• Реальный совет: использовать protobuf только как быстрый бинарный wire-формат, а внутри приложения держать свою доменную модель и писать явные конвертеры.
• Живые альтернативы обсуждаются (Avro, FlatBuffers, Cap’n Proto, JSON+схема), но у каждой свои компромиссы; серебряной пули пока нет.