Язык
Фреймворк - это логическое упорядочивание кода, которое реализует определенную идею, а также набор вспомогательных средств для удобной разработки программных продуктов. Но главную роль для фреймворка, в том числе того, что он может позволить для разработчика, является язык программирования, на котором он написан.
Phoenix Framework написан на языке elixir. В сущности своей язык является “синтаксическим сахаром” для другого известного ЯП erlang. Но самое главное в нем то, что он написан рубистом (Jose Valim) и смотря на код elixir нельзя не заметить насколько велико влияние ruby на elixir. Но некоторое сходство можно найти только в синтаксисе. Все остальное - структуры данных, управляющие блоки - все здесь по другому. Основное, что нужно помнить про elixir - это функциональный язык программирования! Это значит никаких объектов! Но, как оказалось, и без них можно обойтись.
Структура фреймворка
Phoenix является MVC фреймворком. Структурирование очень напонимает рельсы:
- web/controllers - здесь находятся контроллеры;
- web/models - здесь находятся модели;
- web/views - здесь находятся вьюхи.
Но если вы зайдете в web/views, то не найдете там ни одного темплейта. Здесь начинается интересная особенность phoenix.
Для шаблонов имеется другое место в фреймворке - web/templates. А что же тогда views? Оказывается views - это не то, что мы привыкли видеть в рельсах. В Phoenix Framework views выполняют следующие функции (по крайней мере то, что мне удалось выяснить на данный момент):
- рендеринг темплейтов. В рельсах рендерингом теплейтов занимается контроллер. Здесь данная функциональность вынесена в отдельный класс. И, на мой взгляд, это очень интересное решение, т.к. в рельсах нельзя было, кроме контроллера, отрендерить темплейт;
- содержит набор вспомогательных функций, которые можно использовать в темплейтах. В рельсах для этого создавались так называемые helpers.
Доступ к данным
Есть несколько вариантов того, где хранить данные:
- использовать БД mnesia, которая написанная на erlang и является родной для elixir также;
- использовать аналог ActiveRecord, который называется Ecto. На данный момент есть адаптеры для postgresql и mysql. ActiveRecord эта библиотека, конечно, мало напоминает, но она сразу идет из коробки и является, таким себе, стандартным решением.
Ecto поддерживает практически весь необходимый функционал по работе с данным, которым мы привыкли пользоваться в рельсах:
- создание БД с помощью специального mix таска;
- создание моделей;
- генерирование миграций;
- ассоциации;
- валидации;
- CRUD операции и т.д.
Ассеты
Из коробки компиляция ассетов происходит с помощью nodejs пакета brunch. Т.е. если вы хотите писать ассеты на coffeescript и sass, то нужно также ставить nodejs. При деплое на продакшн необходимо принудительно выполнять специальную команду для прекомпиляции. На первый взгляд все понятно и прозрачно, еще не успел наспотыкаться)
На момент написания статьи вышла новая версия Phoenix Framework 0.12.0. В ней появился новый mix таск для прекомпиляции ассетов, наподобие, `rake assets:precompile` в rails.
Разработка
В процессе разработке я не заметил каких-то значимых особенностей. Очень похожая инфраструктура с рельсами:
- есть свой пакетный менеджер;
- большое количество библиотек, плагинов;
- есть свой аналог rake тасков - mix;
- генерирование приложения с помощью mix таска;
- различные scaffold генераторы;
- есть свой аналог Gemfile’а - mix.exs.
В общем с точки зрения рельсовика все довольно похоже. Команды только называются по другому, но семантически они выполняют теже действия.
Деплой
Очень важным шагом является деплой своего приложения на продакшн. Инфраструктура rails немного разбаловала нас, что деплой можно делать всего одной командой. Хотя начальная настройка бывает затяжной. А также разгребание после очередного деплоя тоже :-) Но все же все понятно и очевидно. В официальной документации нет целостной картины, что из себя представляет деплой phoenix приложения и как его готовить.
Я столкнулся с множеством интересных моментов, когда пытался залить приложение на сервер, но все же через несколько часов попыток все заработало. На самом деле проблемы связаны даже не с самим фреймворком, а с незнанием, что делать с языком и его окружением - erlang и его виртуальной машиной. Для людей знающих все это труда не составит, но вот программисту-рельсовику придется голову поломать.
В своей следующей статье я более подробно остановлюсь на этом вопросе.
Заключение
Я не пытался сделать подробное описание всех особенностей или сравнение с рельсами. Это просто вольные мысли насчет первого опыта создания приложения с использованием Phoenix Framework. Учитывая все факторы, а также, что еще идет активная разработка, то я считаю этот опыт положительным и вселяющим надежду, что Phoenix Framework станет отличной альтернативой Ruby on Rails. Будем с охотой наблюдать за развитием!