04.04.2017 13:19
php_freelancer 20 7300 Источник
Symfony 4.0 выйдет в релиз в конце ноября 2017 года. Следующие несколько недель будут опубликовываться статьи о новых идеях и основных изменениях в Symfony 4.

Symfony 3.0 был скучным и являлся более лаконичной версией Symfony 2.8:
Symfony 3.0 = Symfony 2.8 — Deprecated Features.

Но что же будет представлять из себя Symfony 4.0 в отличии предыдущих версий:
Symfony 4.0 = Symfony 3.4 — Deprecated Features + Новые концепции разработки приложений.

Или вот еще один вариант развития событий:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x — Deprecated Features + Новые концепции разработки приложений.

Но самое главное — Symfony 4.0 будет требовать PHP 7. А теперь о новых концепциях разработки.

У Symfony достаточно громоздкий процесс установки внешних бандлов:


На данный момент установка нового бандла одним композером зачастую не обходится.

Как это обычно происходит:

  • Загрузка необходимых зависимостей через composer require symfony/bundle
  • Регистрация бандла в app/AppKernel.php
  • Регистрация маршрутов, которые предоставляет наш новый бандл, если таковые имеются
  • Регистрация необходимых настроек для бандла в app/config/config.yml

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

Теперь посмотрим на 3 и 4 этапы. Процесс регистрации конфигов для новых бандлов вполне реально автоматизировать, но скорее всего это будет выглядеть как обычная вставка стандартного набора настроек для бандла, при котором он может стабильно функционировать, как это сделано в Symfony Standart Edition для некоторых предустановленных пакетов.

Ведь если вы взгляните на README любого популярного бандла: все они начинаются с одних и тех же танцев с бубном — как сконфигурировать то, что вы только что установили.

Удаление бандла в Symfony — это еще большая боль


Если вам необходимо удалить сторонний симфони бандл, который вы недавно установили, то вам недостаточно будет сделать composer remove symfony/bundle. Помните, что нам нужно проделать при установке нового бандла? Ну так вот, теперь нам необходимо так же вручную удалять всё то, что мы тогда понаписали.

В Symfony Standart Edition тоже не все так хорошо


Команда Symfony уже предпринимала попытку предоставить разработчикам определенную отправную точку для начала разработки определенных типов веб-приложений.

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

Но что если вы хотите сделать API или Web Service? А может вы хотите собственный Micro Framework Style?

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

Другой вопрос с дистрибутивами это то, что возможно вы не хотите хранить в своем проекты файлы типа: LICENSE и README. Многие проекты не имеют MIT лицензии вообще, как зачастую может не быть необходимости и в README.

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

Еще не убедил? Посмотрите на README REST дистрибутива:
image

Понятие дистрибутива не очень подходит Symfony


И, наверное, поэтому дистрибутивы Symfony никогда не взлетали. Помимо Standart Edition, ни один из них не пользуется популярностью, поэтому мы опубликовывали только 3 из них:
Hello World Edition, Symfony CMF Standard Edition, Symfony REST Edition.

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

Идеальный вариант


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

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

Композицию наследованию


Большинство дистрибутивов представляют из себя форки Symfony Standart Edition с дополнительными бандлами. А что насчет композиции? Что если я хочу использовать дистрибутив API с Admin? Нужны ли мне здесь новые дистрибутивы? Возможно нет.

Symfony Flex — новый способ, который позволяет создать и поддерживать ваше приложение с легкостью. Это то, что упрощает создание приложений любых типов, от самых простых проектов в Micro-Framework Style, до проектов с огромным количеством зависимостей. Он автоматизирует добавление и удаление пакетов, заботится о том, чтобы задать без вашего участия разумную конфигурацию для нового пакета и многое другое.

Symfony Flex будет использоваться по умолчанию для управления приложениями на Symfony 4, тем не менее он будет доступен в качестве необязательного компонента для управления приложениями на Symfony 3.3 и 3.4. Альфа версия Symfony Flex будет выпущена перед выходом Symfony 4.

Оставайтесь с нами, следующий пост расскажет вам больше о Symfony Flex. А пока оценим новый скелет приложения с Symfony Flex. Не совсем то, что вы ожидали, верно?
Поделиться с друзьями
-->

Комментарии (20)


  1. Fractalzombie
    04.04.2017 23:12
    #10154562

    Интересно, очень.


  1. hanovruslan
    05.04.2017 09:04
    #10154934
    +3

    В этой части


    У Symfony достаточно громоздкий процесс установки внешних бандлов
    Упущен довольно важный кусок из истории возникновения composer-а

    Fun fact: Composer started as a conversation about how to generically install bundles/plugins/extensions for Symfony and phpBB.

WTF fact: Neither Symfony nor phpBB uses Composer as a way to install its bundles/plugins/extensions.


  1. shchedrakov
    05.04.2017 10:34
    #10155210

    Заинтриговало, однако, я так и не понял как именно мне поможет Symfony Flex. В техническом плане. За счет чего он сэкономить мне время… flex будет каким-то магическим образом прописывать для меня нужные конфиги бандлов? Или же с легкостью удалить ненужные пакеты из проекта в один клик?

    Лично в моей практике добавление/удаление бандла занимает примерно 0.1% от общего времени работы над проектом. А вот рефакторинг кода после такой операции берет действительно много времени. Но разве флекс способен в этом помочь? Не думаю. В общем вопрос много, ответов нет, ждем продолжение статьи.


    1. php_freelancer
      05.04.2017 10:56
      #10155286

      Ну вряд ли нам конечно предоставят какой нибудь ИИ, который будет делать за нас все + еще и тапки приносить. Скорее всего произойдет снятие определенных рамок и немного философии о свободе прав кода и правильной расширяемости приложения. Symfony Flex будет давать возможность управлять приложением гибко (на то он и Флекс), позволит наращивать только в нужном направлении, т.е. не иметь никаких стен.

      Пример даже из статьи, если нам нужен REST + Admin, то мы больше не будем нуждаться в целом дистрибутиве под это дело, т.к. теперь мы можем свободно нарастить наше приложение, добавив как REST, так и Admin — и всё это без мяса и с львиной долей гуманизма и жвачки. Композицию наследованию!!!

      «Symfony Flex должен привнести к искоробочности еще и гибкость выбора» — цитата одного из разработчиков в чате.


      1. shchedrakov
        05.04.2017 11:15
        #10155334

        Ну вот опять же. Буквально сейчас пишу проект в котором Admin Panel + API. Что я сделал, взял стандарт эдишет, накатил FOSRestBundle, сконфигурировал его. Потратил часа два времен. После двух недель работы над эндпоинтами заказчики приняли решение, что нужна админка. Накатил FOSUserBundle, сконфигурировал его. Что бы код для эндпоинтов не пересикался с админкой, завел новый фронтконтроллер и отдельные для него конфиги (те в проекте есть фронконтроллеры app_api.php app_admin.php и конфиги config.yml config_api.yml config_admin.yml не буду тут подробно расписывать).


        Я это к тому, что на мой взгляд я и сейчас отлично наращиваю функционал в нужном мне направлении, при этом довольно гибко и легко как по мне. И мне как-то воображения (или знаний) не хватает, что бы хотя бы примерно представить, как же Flex для меня еще упростит эту задачу.


        1. VolCh
          05.04.2017 16:17
          #10156100

          Навскидку у вас там ненужные вам доктрина, монолог, свифтмэйлер, твиг.


          1. shchedrakov
            05.04.2017 16:27
            #10156122

            Интересная вскидка. Доктрина, монолог нужны как в админке так и в АПИ. "свифтмэйлер, твиг." нужны в админке. Но даже если бы и не были нужны, суть то вопроса вообще не в этом. Я могу их отключить, довольно быстро, буквально минут 10-20 времени.


            1. shchedrakov
              05.04.2017 16:34
              #10156140

              Собственно это было сделано мной. Когда обращение идет к АПИ ни твиг, ни сфитмейлер не подгружаются. И наоборот когда обращаемся к админке, бандл FOSRestBundle не подгружется.


            1. VolCh
              05.04.2017 17:47
              #10156264

              Вы на это не указали. У меня сейчас не меньше трети проектов в продакшене, которые используют максимум монолог.


      1. hanovruslan
        05.04.2017 11:18
        #10155346

        имхо


        composition over inheritance

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


        Конечно же, если обсуждать этот принцип сам по себе, то его достоинства и минусы очевидны и сейчас, имхо, он более уместен, чем, например, лет 5-10 назад.


    1. eidicon
      05.04.2017 11:01
      #10155302

      Полностью поддерживаю Ваш комментарий.


    1. Fesor
      09.04.2017 13:01
      #10162440
      +1

      А вот рефакторинг кода после такой операции берет действительно много времени.

      Это как простите?


      Типа был у вас код который был завязан на пакет А и мы решили перейти на пакет Б и для этого придется переписать/написать новые адаптеры? Ну ок, этот процесс не автоматизируется никак. Но это и не "рефакторинг". Рефакторинг это когда у вас были размазаны зависимости по коду и вы решили перейти на другую библиотеку и для этого применили инверсию зависимостей и работу с библиотекой зашили в свой адаптер.


      1. shchedrakov
        09.04.2017 20:37
        #10162694

        Спасибо. Действительно, "рефакторинг" неподходящее слово. Но я писал немного о другом, вы не за ту часть текста зацепились. Добавлять/удалять плагины мне и сейчас вполне удобно, и если флекс улучшит этот аспект, то на мой взгляд, это незначительное нововведение.


        1. Fesor
          09.04.2017 20:59
          #10162720

          Добавлять/удалять плагины мне и сейчас вполне удобно

          Процесс добавления бандла в симфони очень простой. Но он достаточно сложен что бы люди воротили свои сборки куда включают даже те зависимости которые могут пригодиться на одном проекте из четырех. То есть сейчас процесс добавления/удаления зависимостей может и занимает у вас 0.1% от времени разработки (хотя больше, уверяю, надо ж еще документацию почитать да настроить) но упрощение этого процесса увеличит степень реюза кода.


          К примеру есть пара бандлов для организации oauth аутентификации и т.д. Они требуют настройки. Более того, большинство из тех что я видел ориентируются на старые добрые web странички и если access token придет вам в готовом виде с клиента 80% кода библиотеки можно выкинуть. А сделать удобную обертку опять же в виде бандла уже будет не так тривиально, так как надо уже говорить разработчику "а вот тут подключи два бандла и строго в таком порядке".


          Так же часто ловлю разработчиков на том что они часто пишут велосипеды потому что "ну это ж надо бандл найти, подключить, проверить… лень… тут же 5 минут самому написать".


  1. parotikov
    05.04.2017 10:34
    #10155212

    Все-таки нужно различать установку и подключение бандлов.
    С симфони плохо знаком, но в ларе такой же подход унаследован — стянул пакет, затем подключил в конфиге. Для минимизации рутинных действий с конфигами и всякими ассетами есть консольная команда (vendor:publish), но подключение сервис-провайдера в ядре не избежать, да это и логично: может у меня в зависимости от окружения разный набор пакетов подключается.


  1. hanovruslan
    05.04.2017 10:49
    #10155272

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


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


    1. pbatanov
      05.04.2017 11:51
      #10155432

      Я подозреваю, что процесс установки сведут к 

      composer require --dev vendor/dev-depdency
composer require vendor/depdency


      Скорей всего ядро будет ориентироваться только на прямые зависимости. Автоконфигурация будет производиться тоже за счет наличия явно подключенного пакета.

      Например есть компонент symfony/form. При его наличии в секции require будет происходить установка ключа framework.forms в положение ~. Аналогично, если установлен метапакет, замещающий symfony/form (например, symfony/symfony)

      Это уже реализовано в 3.3-dev. Аналогично можно поступать с другими пакетами. Бандлам, я полагаю, будет предложено иметь «дефолтную конфигурацию» и\или иметь стандартные точки расширения, например какой нибудь symfony/security-bundle с помощью symfony/doctrine-bridge может найти единственную сущность, имплементирующую UserInterface и автоматически подключить в качестве провайдера пользовательских аккаунтов. Zero-configuration.

      Фантазировать можно много, идея в целом годная. Остается только ждать )


      1. hanovruslan
        05.04.2017 12:02
        #10155450

        Кстати да. на этот случай же уже есть секция bin (копирование все этих скриптов из пакета в проектный bin) к композере. если я ничего не путаю, к этому делу можно добавить условно безопасный запуск всего, что есть в проектном бине и будет уже что-то с чем можно работать. не надо перехреначивать конкретный фреймворк… на самом деле надо, конечно, но по другой причине 8)


  1. krocos
    05.04.2017 20:04
    #10156510

    Эта новая штука flex, как мне кажется, — нечто похожее на symfony installer по философии появления. Последний появился для того, что бы не писать create-project и не ждать пока composer решит зависимости, а набрать new и получить снапшот (если я не ошибаюсь) каркаса быстро. Типа сахар, только не синтаксический, а терминально-командный. А на практике я еще ни разу (кроме теста из любопытства) не пользовался этим инсталером.


    1. pbatanov
      06.04.2017 08:26
      #10156878

      Аналогично. Первая мысль, которая придет мне в голову, если я начну клепать сайты на симфони раз в неделю — это сделать свой отдельный пакет и разворачивать его через create-project