Убили ли контексты Phoenix? Разбираемся в причинах малой популярности фреймворка

Биткойн

Phoenix — это мощный и современный веб-фреймворк, построенный на базе языка программирования Elixir. Несмотря на все свои достоинства и высокие оценки со стороны разработчиков, Phoenix так и не стал по-настоящему массовым, оставшись нишевой технологией с верной, но относительно небольшой аудиторией. Почему при таком большом количестве положительных отзывов и высокой оценке на популярных опросах интерес к Phoenix не нарастает одинаково быстро, как у других крупных веб-фреймворков? Одной из главных причин называют введение в Phoenix 1.3 архитектурного паттерна — контекстов. Давайте разберёмся, что же такое контексты, как они повлияли на экосистему и действительно ли именно они стали причиной ограниченной популярности Phoenix.

Контексты появились с целью привести архитектуру Phoenix в соответствие с принципами предметно-ориентированного проектирования (Domain-Driven Design). Главная идея заключалась в том, чтобы разделять приложение на отдельные логические домены, каждый из которых изолирован от других и предоставляет ограниченный набор функций, необходимых для реализации бизнес-логики. Такой подход позволяет создавать более чистую, масштабируемую структуру кода и упрощает сопровождение крупного проекта. С точки зрения зрелого разработчика, который работает с большим кодовым базисом, контексты — отличный способ структурировать сложные приложения и избежать грязной взаимозависимости между появляющимися в проекте модулями. Однако у этой идеи есть и обратная сторона.

Для новичков и тех, кто только начинает проект с нуля, необходимость сразу задумываться над тем, как распределять весь функционал по контекстам, становится значительным барьером. Проблема усугубляется отсутствием чётких рекомендаций о том, как и когда выделять отдельные контексты. Например, назвать контекст зачастую сложнее, чем саму сущность или модель. При создании простой блоговой платформы в Rails нужно лишь определить модель Post, и многие первичные шаги выполняются автоматически. В Phoenix же нужно придумать название для контекста — Блог, Аккаунты, Модерация или что-то другое — что приносит дополнительную нагрузку на мышление и часто приводит к замедлению процесса разработки.

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

Кроме того, стоит отметить, что Phoenix никогда не обладал мощным институциональным продвижением, аналогичным тому, что имели TypeScript от Microsoft или Go от Google. Это усложняет задачу популяризации технологии, особенно в условиях зрелого рынка с множеством устоявшихся и широко применяемых фреймворков. Интерес к Phoenix заметно снизился примерно с 2017 года, что совпадает с выпуском версии 1.3 и распространением практики использования контекстов. Несмотря на последующий всплеск внимания к Phoenix около 2022 года, общий тренд показывает, что популярность фреймворка остается на уровне значительно более низком, чем у его прямых конкурентов.

Разумеется, винить только контексты было бы несправедливо. Это всего лишь один из факторов, влияющих на восприятие Phoenix и сложность его изучения для новичков. Но он явно вносит свою лепту. Можно говорить о том, что контексты выделяют избыточную сложность на ранних этапах развития приложения и тормозят скорость обучения, что, в свою очередь, снижает расширение сообщества и доступность работы с Phoenix. Что же делать? Сообщество Phoenix стоит перед выбором между архитектурной чистотой и прагматизмом.

Rails, например, добился своей ошеломительной популярности благодаря простоте начала работы и минимальному сопротивлению новичков при создании первых приложений. Возможно, Phoenix стоит пойти туда же — обеспечить упрощённый режим для начинающих разработчиков, где контексты выступают не как обязательный конструктив, а как рекомендованная практика для более продвинутого этапа. Кроме того, есть потенциал для улучшения инструментов, которые помогут автоматически создавать и структурировать контексты, освобождая пользователя от необходимости вникающего выбора названий и архитектурных решений. Усиление конвенций и создание более чётких стандартов использования контекстов может свести к минимуму «байкшединг» и сделать процесс развития с Phoenix более предсказуемым и плавным. Важно помнить, что архитектурные новшества должны работать на пользователя, а не становиться препятствием.