Hacker News Digest

FastAPI Voyager - это интерактивный инструмент визуализации для API, созданный на базе FastAPI. Позволяет наглядно представлять структуру API с возможностью масштабирования через прокрутку и детального изучения узлов двойным кликом. Особенность инструмента - режим просмотра зависимостей схемы (активируется через Shift+клик), который фильтрует несвязанные узлы, упрощая анализ сложных систем.

Проект поддерживает импорт данных JSON из ядра системы, что обеспечивает гибкость интеграции. Инструмент ориентирован на разработчиков, работающих с FastAPI, и помогает лучше понимать архитектуру API, выявлять связи между компонентами и оптимизировать структуру. Код проекта доступен на GitHub, что позволяет сообществу вносить вклад в развитие и адаптацию инструмента под конкретные нужды.

• Пользователи жалуются на неудобство визуализации сложных связей между эндпоинтами и моделями ответов в fastapi-voyager; требуется более интерактивный и «чистый» способ исследовать схему.
• Предложение: добавить взаимодействие при наведении курсора на узел, чтобы подсвечивать связанные с ним линии и скрывать остальные, а также дать возможность «проваливаться» внутрь подграфа.
• Пользователи просят улучшить UX: убрать «клубок» линий, дать возможность масштабировать и фильтровать отображаемое, а также предоставить обзорный режим, в котором детали раскрываются по мере необходимости.
• Проект вдохновлен GraphQL-voyager, но не реализует его фичи вроде подсветки связей при наведении мыши; автор отвечает, что проект на ранней стадии и приветствует PR-ы.

Каталог WeUseElixir собирает реальные примеры использования языка Elixir в продакшене, демонстрируя разнообразие его применения — от библиотек до крупных компаний. Здесь можно найти такие известные инструменты, как Oban для обработки фоновых заданий, Absinthe для работы с GraphQL и Flop для пагинации в Ecto.

Среди компаний, применяющих Elixir, — PepsiCo, платформа для стриминга концертов VEEPS и сервис удалённой работы Remote. Каталог помогает разработчикам находить вдохновение, инструменты и потенциальных работодателей, подчёркивая практическую ценность экосистемы Elixir.

• Участники высоко оценивают язык Elixir, его подход к функциональному программированию, параллелизму и сообщество, отмечая его эффективность для проектов любого масштаба.
• Были предложения по улучшению каталога WeUseElixir: добавить фильтрацию по типам проектов, разрешить добавлять компании без регистрации и исправлять данные о стеках технологий.
• Обсуждались технические аспекты: преимущества BEAM (виртуальной машины Erlang) для отказоустойчивости, продуктивность фреймворка Phoenix LiveView и варианты интеграции с клиентским состоянием.
• Участники поделились известными компаниями и проектами, использующими Elixir (например, Plausible Analytics, Supabase, ElectricSQL), и другими подобными каталогами.
• Задан вопрос о выборе между языками экосистемы BEAM: Erlang (для опытных команд), Elixir (общего назначения) и Gleam (строгая типизация).

Как мы взломали Burger King: обход аутентификации = прослушка драйв- thru

Старт
RBI (Burger King, Tim Hortons, Popeyes) управляет 30 000 точек через платформу «assistant». Уязвимости позволяли открыть любую из них и слушать разговоры у окна заказа.

Дыры

1. Регистрация без проверки почты: GraphQL-мутация signUp создавала аккаунт мгновенно; пароль присылали открытым текстом.
2. Список всех магазинов: инкрементный storeId + запрос getStore → персонал, конфиги, id.
3. createToken без авторизации: передал storeId – получил master-токен.
4. Повышение до админа: updateUser(roles: "admin") одной мутацией.
5. Сайт заказа оборудования: пароль «защищён» клиентским JS, сам пароль в HTML.
6. Планшеты в зале и драйв-thru:
   • главный экран /screens/main?authToken=… – история разговоров с аудио;
   • диагностика /screens/diagnostic – пароль admin, регулировка громкости и запись звука в реальном времени.

Итог
Одна уязвимая GraphQL-точка → полный контроль над глобальной сетью, персональными данными и живыми разговорами клиентов.

• Пост исследователя безопасности о дырах в IT Burger King удалили после жалобы DMCA от стартапа Cyble.
• Уязвимости были клиент-side-only пароль в HTML, незащищённые голосовые записи, привязка голоса к имени и номеру авто.
• Автор сообщил Burger King заранее, получил молчание и нулевой бонус, после публикации — DMCA-удаление.
• Комментаторы обсуждают: злоупотребление DMCA, отсутствие bug bounty, этика публичного разоблачения и перспективы тюрьмы за CFAA.

• Данные на странице IMDB иерархические: фильм → режиссёр, жанры, актёры → персонажи.
• Иерархия двунаправленная: фильм→актеры и актер→фильмы.
• Реляционная БД хранит всё в плоских таблицах; при выводе строим нужную иерархию.
• Ручная сборка — утомительна, это «объектно-реляционное несоответствие».

SQL не умеет выдавать структуру
Цель: JSON вида

{"title":"Baby Driver","director":["Edgar Wright"],"writer":["Edgar Wright"],
 "genres":["Action","Crime","Drama"],
 "actors":[{"name":"Ansel Elgort","characters":["Baby"]}, …]}

Пошаговые запросы:

-- название
SELECT primaryTitle FROM title WHERE tconst='tt3890160';

-- режиссёры
SELECT p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='director';

-- сценаристы
... AND pr.category='writer';

-- актёры
SELECT p.nconst, p.primaryName
FROM title t
JOIN principal pr ON t.tconst=pr.tconst
JOIN person   p  ON pr.nconst=p.nconst
WHERE t.tconst='tt3890160' AND pr.category='actor';

-- персонажи
SELECT pc.nconst, pc.character
FROM title t
JOIN principal pr          ON t.tconst=pr.tconst
JOIN principal_character pc ON pr.nconst=pc.nconst
WHERE t.tconst='tt3890160';

Попытка объединить всё в один запрос даёт декартово произведение (режиссёры×сценаристы) и пропуск записей при отсутствии одной из ролей. Поэтому приходится делать множество отдельных запросов и собирать итоговую структуру на клиенте.

• Обсуждение крутится вокруг «объектно-реляционного несоответствия»: SQL хорошо хранит нормализованные данные, но плохо отдаёт их иерархически.
• Многие считают, что виноват сам язык: нет встроенных вложенных отношений, агрегация в JSON делается громоздко, JOIN-ы приходится «переделывать» в коде.
• Часть участников предлагает решать задачу внутри СУБД: Postgres-функции json_agg, LATERAL-подзапросы, денормализованные VIEW и «JSON-проекции».
• Другие уверены, что проблема надумана: деревья в SQL вполне строятся (adjacency list, nested sets, closure table), просто нужно знать приёмы; ORM и NoSQL лишь откладывают боль.
• Упоминаются альтернативные пути: GraphQL-слой поверх SQL, графовые СУБД, документные хранилища (MongoDB), event-sourcing с CQRS, но каждый имеет свои trade-off.

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

Проанализировав реверс-инжиниринг и доклады команды Linear, я понял: их sync-движок — это месяцы работы, чтобы решить офлайн-режим, конфликты, частичную синхронизацию, миграции схем и безопасность.

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.