Hacker News Digest

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Elixir-миф #1: «Let it crash»

Фраза «let it crash» вводит в заблуждение: звучит так, будто приложение падает, хотя речь всегда идёт об отдельном процессе, который супервизор мгновенно перезапустит. Приложение при этом живёт.

Проблема: процессы связаны с реальными вещами — сокетами, HTTP-запросами, файлами, БД. Пример LiveView:

def handle_event("import_data", %{"data" => data}, socket) do
  Enum.each(data, &create_item/1)
  {:noreply, socket}
end

Код упадёт, если:

• имя события не совпадёт;
• нет ключа "data";
• data не список;
• ошибка в create_item/1.

Первые три случая — скорее баг фронтенда, падение допустимо. Но последний — ошибка валидации одного элемента, и из-за неё весь веб-сокет пользователя рвётся, UI пропадает. Это плохой UX.

Что делать вместо «let it crash»

1. Валидируй вход до бизнес-логики.
2. Возвращай ошибки пользователю, а не падай.
3. Перезапускай только то, что действительно сломалось (например, соединение с БД), а не весь контекст пользователя.

Слоган лучше переформулировать:
«Не позволяй падать — позволяй исцеляться».

• «Let it crash» — это не призыв игнорировать ошибки, а концепция быстрого восстановления через дёшёвые процессы и деревья супервизоров BEAM.
• Слоган выглядит провокационно, но подразумевает, что система спроектирована так, чтобы падение одного процесса не рушила всё приложение.
• Ключевой источник — докторская диссертация Джо Армстронга «Making reliable distributed systems…», которую участники считают обязательной к прочтению.
• Перезапуск не решает фундаментальные проблемы (отсутствие конфигурации и т. д.), но помогает с транзиентными сбоями и временными условиями.
• Если ошибка повторяется, дерево супервизоров поднимает её всё выше, пока приложение либо восстановится, либо окончательно упадёт.