YiiFramework Новости Yii 2020, выпуск 7

Sam Dark

Новичок
Всем привет! Это очередной выпуск новостей Yii. Как обычно, в выпуске вас ждут релизы Yii 2, прогресс Yii 3, важные вести о Yii 1 и другие новости. Приятного чтения и будьте здоровы. - Александр Макаров
Фонд
С прошлого выпуска пришлось прилично отвлечься на фонд, а именно на то, как средства перебрасываются из GitHub Sponsors в OpenCollective. С GitHub они уходили нормально, а вот куда - большой вопрос. Потребовалось время, чтобы разобраться, но проблему удалось решить.
Ещё одна новость, частично связанная с фондом. Автор httpsoft/http-message, Евгений Зюбин, вероятно присоединится к команде фулл-тайм если/когда это позволит пополнение фонда. Если вы или ваша компания хотите получить Yii 3 раньше, можете помочь.
Инфраструктура
Мы постоянно улучшаем процесс тестирования пакетов:
  • В пакеты со стабильной версией добавлена проверка Roave backwards compatibility. Она проверяет что публичный API не сломан по-сравнению с предыдущим стабильным релизом.
  • Мы продолжили перевод тестов с Travis на GitHub actions как для Yii 2, так и для Yii 3. Actions классные, а Travis не так давно порезал поддержку OpenSource. Хорошо что мы начали переход заранее.
  • Мы решили не собирать покрытие кода через PHPUnit с последующей отсылкой его в Scrutinizer CI и теперь генерируем отчёт о покрытии средствами Scrutinizer. Это значительно быстрее, а результат тот же.
  • Отлично себя показал Psalm. Рекомендуем, в том числе, для ваших проектов.
  • В консоль GitHub actions теперь всё выводится в цвете. Выглядит значительно лучше!
Немного правок были сделаны на сайте. Прежде всего это переход на новый метод аутентификации GitHub API. Также был сделан ряд небольших улучшений фронтенда.
Патчи для совместимости с PHPUnit для Yii 2 и Yii 1 переехали в отдельный репозиторий. Если вдруг вам понадобится тестировать приложение на версиях PHP с 5.3 по 8, репозиторий будет определённо полезен.
🔷 Yii 1
🔷 Yii 2
Был выпущен Yii 2.0.39. В нём есть улучшения DI-контейнера и дополнительные исправления для работы с PHP 8.
Чуть менее заметное улучшение коснулось способа генерации аннотаций для магических свойств. Теперь некоторые IDE, включая PhpStorm, будут отличать свойства только для чтения и только для записи.
Были выпущены новые версии следующих расширений:
🔶 Yii 3
С прошлого выпуска были сделаны следующие релизы:
На данный момент мы готовим пакеты из списка в карточке Trello.
Был принят ряд интересных решений:
  • Все стабильные релизы будут начинаться с версии 1.0.0. Ранее рассматривался вариант начинать с 3.0.0.
  • Пакеты Yii 3.0 буду поддерживать PHP 7.4.
  • В большинство пакетов добавлена конфигурация по-умолчанию. Они будут работать сразу после установки без дополнительной конфигурации или с очень минимальной конфигурацией.
  • Провайдеры конфигурации были удалены почти из всех пакетов и приложений.
В Trello есть доска с задачами, над которыми мы работаем, включая не отражённые в GitHub issue.
Почти каждый из пакетов был серьёзно почищен, получил совместимость с PHP 8 и исправления. Ниже представлено самое интересное.
Новые пакеты
Был создан ряд новых пакетов. Часть из них появились в результате выделения общего кода из других пакетов, а часть - нет.
Инструменты для разработки
  • Были актуализированы зависимости и добавлен Dockerfile.
  • Реализована возможность полу-автоматического выпуска релизов.
Composer config plugin
Была добавлена временная поддержка PHP 8. Она не заменяет вариант с переписыванием плагина на AST и нужна для того, чтобы облегчить тестирование под PHP 8 в то время как мы занимаемся версией с AST.
Контейнер и фабрика
Кеш
Bulma
  • Больше документации, улучшено именование.
  • Добавлена возможность использовать значки в выпадающем меню.
  • Все виджеты сделаны иммутабельными.
Роутер
  • Внутренности и конфигурация упрощены путём выделения коллекции маршрутов в отдельный класс.
  • Метод UrlMatcherInterface::getLastMatchedRequest() удалён, добавлен getCurrentUri().
  • UrlMatcher теперь является опциональным, что хорошо сочетается с консольными приложениями.
Шаблоны приложений и демо
  • Больше не требуется NodeJs. Ресурсы забираются через asset packagist.
  • Конфиги значительно почищены. В app мы поделили их по разным пакетам.
  • Убрана ссылка контейнера на себя.
  • В yii-demo добавлен Swagger. Открывается через /swagger.
  • yii-demo подвергся рефакторингу.
  • Заменили в yii-demo реализацию PSR-7 на httpsoft/http-message.
Var dumper
Files
Cycle
  • В файловую схему теперь можно писать. Также в неё добавлена поддержка чтения из нескольких файлов.
  • Был задействованы наши DI контейнер / фабрика, так что интеграция с Cycle теперь работает на PHP 8.
Data
DBAL и ActiveRecord
Как DBAL, так и ActiveRecord, портированные с Yii 2, ещё рефакторить и рефакторить несмотря на то, что их серьёзно почистили и они, по большей части, работают.
Arrays
HTML
Debugger
Очереди
Translator
Пакеты i18n помечены как устаревшие, добавлены пакеты translator с новым дизайном.
📙 Новая и изменённая документация
📚 Рекомендации к чтению и другие новости
❤Спасибо!
Хочу сказать спасибо всем спонсорам и разработчикам, благодаря которым стала возможна разработка Yii 3. Вместе у нас всё получится.
👍 Отдельное спасибо тем, кто помог Yii 3 кодом:
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Определения сервисов в конфигах-массивах - это жаль, лучше бы в аннотациях.
Для декларации сервисов нужен синтаксис с поддержкой lazy load, weak reference, typed и named arguments. Бывает нужен и service subscriber.
Мне кажется, не стоит тратить силы на то, что явно не дотягивает до аналогов. За 10 лет отработаны стандартные и стабильные реализации DI на выбор.

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

AR из yii2 - вообще отдельная тема, его не рефакторить надо, он устарел капитально. AR после yii1 - так, рестайлинг, отрефакторили внутри, но развития нет. Его надо перепридумывать.
PHP:
$query = new ActiveQuery(Customer::class, $this->db);
Убираете статические вызовы find() для того, чтобы хардкодить имена классов, проще писать или понятней читать от этого не становится.
Менять синтаксис - это само по себе плохо, это должно оправдываться серьезным улучшением, а тут вывернули AR наизнанку, соглашения заменили внешней зависимостью, код приложений сделали более хрупким, то есть, сделали хуже.

$this->arFactory - это нарушение SOLID сразу по 3м пунктам
как говорится, пристрелите меня кто-нибудь :) прошло 10 лет, казалось бы, все прочли Фаулера

чем взял Laravel - упрощением, логичностью, + они решают проблемы консистентности самого php своими либами, а тут вообще непонятно
 
Последнее редактирование:

AmdY

Пью пиво
Команда форума
Для декларации сервисов нужен синтаксис с поддержкой lazy load, weak reference, typed и named arguments. Бывает нужен и service subscriber.
Мне кажется, не стоит тратить силы на то, что явно не дотягивает до аналогов. За 10 лет отработаны стандартные и стабильные реализации DI на выбор.
Мне кажется, название этого класса хорошо раскрывает суть происходящего
PHP:
$object = new EngineVAZ2101();

p.s. Хорошо, что поддерживается старая версия
p.p.s. Хотелось бы увидеть что-то среднее между магическим Laravel и неудобным Symfony, но пока YII3 напоминает путь Zend Framework
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
действительно, хорошее объяснение, действительно, авторы, yii нечасто обращали внимание на мир вокруг
 
Последнее редактирование:

Sam Dark

Новичок
Определения сервисов в конфигах-массивах - это жаль, лучше бы в аннотациях.
В аннотациях чего именно? Если речь про подход аля Spring, то нет, это явно не лучше. Если что-то другое, то хочется услышать более развёрнуто, про что это.

Для декларации сервисов нужен синтаксис с поддержкой lazy load, weak reference, typed и named arguments.
Есть. Разве что weak reference я не понял к чему тут.

Бывает нужен и service subscriber.
Прокси или что имеется ввиду?

Мне кажется, не стоит тратить силы на то, что явно не дотягивает до аналогов.
Пока ничего нет, ничего не дотягивает до аналогов. Не тратить силы вообще ни на что? :)

За 10 лет отработаны стандартные и стабильные реализации DI на выбор.
Никто не мешает выбрать. Из коробки можно менять на любой PSR-совместимый контейнер.

Привязываться к 7.4 - такое дело, будет как с yii 2, когда привязались к 5.х какой-то, но пока писали, 5ка стала никому не нужна, и поближе к релизу стали выпиливать старый код, хотя сразу было понятно, что лучше ставить в требованиях более позднюю версию.
Не так было. В 2014-ом, когда релизнулась первая версия Yii 2, 7-ки ещё не было. Реально переход на 7-ку случился повсеместно где-то 2018-2019.

7.4 будет жить до 2023 как минимум и, несмотря что контейнеры уже не такая экзотика, прям массового перехода на 8-ку прям сразу я бы не ждал.

Убираете статические вызовы find() для того, чтобы хардкодить имена классов, проще писать или понятней читать от этого не становится.
Менять синтаксис - это само по себе плохо, это должно оправдываться серьезным улучшением, а тут вывернули AR наизнанку, соглашения заменили внешней зависимостью, код приложений сделали более хрупким, то есть, сделали хуже.
Это потому что мы его портировали как есть и поправили до состояния "технически пашет". Продолжим развивать - станет приятней. Промежуточный вариант, конечно, совсем не очень. Это ожидаемо.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
В аннотациях чего именно? Если речь про подход аля Spring, то нет, это явно не лучше. Если что-то другое, то хочется услышать более развёрнуто, про что это.
хмм, хороший вопрос, я подумаю

Есть. Разве что weak reference я не понял к чему тут.
чтобы в опциональный параметр инъектить не сам объект, а слабую ссылку

Прокси или что имеется ввиду?
Нет, service subscriber - это когда в модуле нужна куча сервисов, параметров из конфигов, констант сторонних классов,
когда в модуле используются не дефолтные для всего приложения, а особые реализации интерфейсов,
чтобы не писать в коде прямые вызовы Class::constant и не плодить интерфейсы на каждую реализацию,
для модуля декларируется такой service subscriber, для которого прописываются все зависимости, а код внутри модуля остается изолированным от приложения.
По сути, это суб-контейнер для модуля. Инъекция из объекта subscriber в объекты модуля потом пишется самостоятельно, но это 40 строк, включая рекурсивную автозагрузку зависимостей с парсингом параметров.
Это нужно для модульности приложений.

Пока ничего нет, ничего не дотягивает до аналогов. Не тратить силы вообще ни на что? :)
Никто не мешает выбрать. Из коробки можно менять на любой PSR-совместимый контейнер.
да, я регулярно встречаю с yii другие контейнеры,
но я бы не хотел уходить во флейм, у меня нет желания обругать, просто мнение, что другие контейнеры лучше, я встречал в разных проектах у разных людей

Не так было. В 2014-ом, когда релизнулась первая версия Yii 2, 7-ки ещё не было. Реально переход на 7-ку случился повсеместно где-то 2018-2019.
насколько я помню, речь тогда была про 5.3 или 5.4, а стоило сразу брать 5.6, и писать в совместимости с 7

7.4 будет жить до 2023 как минимум и, несмотря что контейнеры уже не такая экзотика, прям массового перехода на 8-ку прям сразу я бы не ждал.
Зависит от ваших целей.
Сейчас не 2014й, есть 5 фреймворков, которые более востребованы для веб, чем yii (не забываем про express и django), за 5 лет они много чего сделали неплохо, и замедляться не собираются.
Yii 3 не ждут, никаких тысяч имплементаций с релизом не появится. Про поддержку версий php стоит думать после десятка удачных релизов в следующие 3 года после основного релиза, и активного продвижения.

То, что 38% интернета - wordpress, никак не относится к версиям php для нового, никому еще не нужного фреймворка.
Если цель - сделать что-то востребованное в мире, надо делать не лучше, чем yii2, а сделать что-нибудь интереснее, чем laravel 9, 10, symfony 5 и express 5. Каким был yii1 с автогенерацией админок на фоне монстров symfony 2 и zf.

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
symfony 2 vs 4 - тяжелый фреймвок для монолитов на макросах превратился в набор lego,
из замкнутой экосистемы перешли на composer и PSR,
по компонентам объединились с laravel и drupal, создали общую экосистему, поделили рынок,
собирай что хочешь, уже не тормозит, из других фреймвоков так кусок не вытащить

laravel 2 vs 8 - из поделки на Codeigniter сварганили целую кучу салатов к дошираку вроде Flysystem, WebSockets с pub/sub, мультиканальные рассылки, OAuth, коллекции с map/reduce, Jetstream, всякие платные CI/CD - кушать подано, садитесь жрать, пожалуйста

yii1 - автогенерация, магия, взлет, yii2 - рестайлинг, приземление, а какой личный бренд yii3?
 
Последнее редактирование:

Sam Dark

Новичок
чтобы в опциональный параметр инъектить не сам объект, а слабую ссылку
Зачем это делать?

Нет, service subscriber - это когда в модуле нужна куча сервисов, параметров из конфигов, констант сторонних классов,
когда в модуле используются не дефолтные для всего приложения, а особые реализации интерфейсов,
чтобы не писать в коде прямые вызовы Class::constant и не плодить интерфейсы на каждую реализацию,
для модуля декларируется такой service subscriber, для которого прописываются все зависимости, а код внутри модуля остается изолированным от приложения.
По сути, это суб-контейнер для модуля. Инъекция из объекта subscriber в объекты модуля потом пишется самостоятельно, но это 40 строк, включая рекурсивную автозагрузку зависимостей с парсингом параметров.
Это нужно для модульности приложений.
Модульность в работе. У нас это будет не так сделано, а делегированием в суб-контейнры.

насколько я помню, речь тогда была про 5.3 или 5.4, а стоило сразу брать 5.6, и писать в совместимости с 7
Нет. В 2014-м, в момент релиза, всё было сделано правильно. Увлеклись поддержкой Legacy и very long term service уже после.


Yii 3 не ждут, никаких тысяч имплементаций с релизом не появится. Про поддержку версий php стоит думать после десятка удачных релизов в следующие 3 года после основного релиза, и активного продвижения.
Ждут. В проде проекты есть уже сейчас :)


5. Каким был yii1 с автогенерацией админок на фоне монстров symfony 2 и zf.
Всё попутал :) Symfony 2 релизнулся после Yii 1.1 (через примерно 2 года), ZF 2 тоже (через примерно 3 года).

symfony 2 vs 4 - тяжелый фреймвок для монолитов на макросах превратился в набор lego,
из замкнутой экосистемы перешли на composer и PSR,
по компонентам объединились с laravel и drupal, создали общую экосистему, поделили рынок,
собирай что хочешь, уже не тормозит, из других фреймвоков так кусок не вытащить
Искажённая картина мира.

1. Symfony - не набор Lego. Да, там есть много компонентов и приличная часть фреймворко-независимы, но ядро для веба и туча пакетов под него не PSR-ное и заменить в Symfony можно не так много по факту. Контейнер тоже.
2. Symfony 2 был как-бы тоже на Composer, так что ремарка про "перешли на Composer" очень странная.
3. Про "создали общую экосистему" - нет. Laravel по факту пользуется наработками конкурента и чутка попиливает сук, на котором сидит (и там и там деньги от complimentary products, но платят за основу и того и того Sensio Labs).
4. Про "уже не тормозит" смешно. Берём тот же бенчмарк TechEmpower. Для простого приложения с доступом к базе получаем что Symfony медленней Yii 2 на 15% (и это да, сильно улучшили, молодцы), а Laravel в лучшем случае вдвое. При этом Symfony для достижения такого результата компилирует контейнер, что прилично всё усложняет во время дебага. В Yii 3 у нас контейнер всё ещё не компилируемый (только конфиги собираются), при этом у нас фреймворк вышел уже быстрее Yii 2.
 

Sam Dark

Новичок
При чём тут вообще бренд? Продукт не готов. Мы не Apple чтобы "ничё не скажем, но будет серебряная пуля, верьте нам" или "вот такие у нас плюсы (про минусы ни слова), у других такого нет, мы лучшие".
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Если ты знаешь тысячу человек, которые начнут проекты на yii3 когда он выйдет, то все хорошо, и все мои тезисы не имеют смысла,
это вопрос довольно простого исчислимого показателя.

Я вижу несколько десятков. Такой сейчас уровень спроса. Понятно, что это только контрибьюторы.
Года за два, если релизы yii3 будут удачными, народ придет и на 3ку, а везде будет 8ка.
Но на момент релиза количество заинтересованных людей, которое я вижу - десятки. Зачем бренд - да чтобы понятно было, почему именно yii.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Искажённая картина мира.

1. Symfony - не набор Lego. Да, там есть много компонентов и приличная часть фреймворко-независимы, но ядро для веба и туча пакетов под него не PSR-ное и заменить в Symfony можно не так много по факту. Контейнер тоже.
Удивлен. Да, у нас противоположное восприятие Symfony.

Мой опыт работы с symfony был именно как с набором компонентов, из которого я собираю то, что мне надо.
Для каждого компонента есть документация, отдельный репозиторий, пакет, lifecycle, инструкция по установке и эксплуатации без остального фреймворка.
Они называют себя "a set of reusable PHP components".
Как это не конструктор? 😳

Ядро я легко делаю свое, добавив их трейт. Контейнер - да, он не psr, они оставили совместимость с 2кой, и в комплекте идет переходник для psr, с yii он комбинируется, получается неплохо.

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

3. Про "создали общую экосистему" - нет. Laravel по факту пользуется наработками конкурента и чутка попиливает сук, на котором сидит (и там и там деньги от complimentary products, но платят за основу и того и того Sensio Labs).
Удивительно, что использование open source компонентов в других продуктах ты воспринимаешь негативно.
Это такая модель бизнеса, когда чем больше пользуются - тем лучше.
В Symfony явно не то что не против, а прилагают много сил, чтобы их использовали как компоненты в других продуктах. Объем работы над документацией и адаптерами для совместимости с PSR для старых компонентов, чтобы их использовали вне фреймворка, очень большой.

4. Про "уже не тормозит" смешно. Берём тот же бенчмарк TechEmpower. Для простого приложения с доступом к базе получаем что Symfony медленней Yii 2 на 15% (и это да, сильно улучшили, молодцы), а Laravel в лучшем случае вдвое. При этом Symfony для достижения такого результата компилирует контейнер, что прилично всё усложняет во время дебага. В Yii 3 у нас контейнер всё ещё не компилируемый (только конфиги собираются), при этом у нас фреймворк вышел уже быстрее Yii 2.
Давай отделим мухи от котлет. Компилируемый контейнер нужен когда у приложения появляется пятый десяток сервисов с параметрами, тут с контейнером yii приходится расстаться, а с симфонивским контейнером я имел дело с 4 тысячами сервисов на >10к запросах в секунду.
Компиляция и дебаг - цена за производительность, кэп.

Ты считаешь с доктриной или DBAL? С предзагрузкой или без?
Возможно, 15% - это вопрос конфигурации. Смешно ли то, что со стандартной предзагрузкой symfony быстрее на 75%? С твоих слов это значит, что symfony может быть на 50% быстрее yii, в котором поддержки предзагрузки нет.
 

Sam Dark

Новичок
Они называют себя "a set of reusable PHP components".
Как это не конструктор? 😳
Называют они себя "a set of reusable PHP components and a PHP framework to build web applications, APIs, microservices and web services." Компоненты != фреймворк.

Удивительно, что использование open source компонентов в других продуктах ты воспринимаешь негативно.
Я совсем не это воспринимаю негативно. Тут примерно та же история как с MongoDB и Amazon DocumentDB. Производная портит приток средств для существования основы, на которой производная строится. С одной стороны чем больше пользуются, тем лучше. С другой - зависит от того, как построен бизнес (и есть ли он). Для Yii чем больше, тем лучше. Причём не важно где. Для Symfony (по-моему мнению) лучше если больше напрямую в продуктах, а не в другом фреймворке, который скрывает за собой основу Symfony. Но тут, конечно, я мысли не читаю... может всё не так.

Давай отделим мухи от котлет. Компилируемый контейнер нужен когда у приложения появляется пятый десяток сервисов с параметрами, тут контейнер yii приходится выбрасывать, а с симфонивским контейнером я имел дело с 4 тысячами сервисов на >10к запросах в секунду.
Компиляция и дебаг - цена за производительность, кэп.
1. Чего это приходится выбрасывать? Ни разу не встречал просадки по производительности в Yii из-за контейнера. Если бы это было так, компилируемый контейнер рвал бы по производительности Yii 2. Но нет.
2. Во-первых, эти 10K явно достигались не единственным сервером. Во-вторых, 4000 сервисов напихать в монолит - это ой.



Ты считаешь с доктриной или DBAL? С предзагрузкой или без?
1. И с Doctrine и с DBAL: https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/PHP/symfony#data-storedatabase-mapping-test
2. С предзагрузкой (причём Yii 2 без неё).
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Я совсем не это воспринимаю негативно. Тут примерно та же история как с MongoDB и Amazon DocumentDB. Производная портит приток средств для существования основы, на которой производная строится. С одной стороны чем больше пользуются, тем лучше. С другой - зависит от того, как построен бизнес (и есть ли он). Для Yii чем больше, тем лучше. Причём не важно где. Для Symfony (по-моему мнению) лучше если больше напрямую в продуктах, а не в другом фреймворке, который скрывает за собой основу Symfony. Но тут, конечно, я мысли не читаю... может всё не так.
Не так. MySQL, Postgres, и скорее всего Mongo тоже, зарабатывает на поддержке проектов, которые выросли, и которым нужна оптимизация.
Oracle и Maria не страдают и не противятся MySQL в Aurora и RDS - все-равно к ним идут за помощью.
Поверь, если бы в Oracle увидели хоть намек на проблемы из-за AWS - в следующей версии был бы запрет. Даже при том, что Oracle продает свой DBAAS, они не против использования MySQL в AWS или где-либо еще.
Аналогично, Symfony не интересны сайтики на Laravel, они зарабатывают на крупных клиентах, которые выросли, и которым нужна помощь. Чем больше проектов начинается на laravel, тем больше когда-нибудь дорастут до потребности в консалинге, а компоненты там из Symfony, и чтобы масштабироваться, все переходят на симфони и сервисы.
Ты ж в курсе, что Skyeng, который раньше писал, что на yii, когда выросл, стал писать, что он на symfony?

1. Чего это приходится выбрасывать? Ни разу не встречал просадки по производительности в Yii из-за контейнера. Если бы это было так, компилируемый контейнер рвал бы по производительности Yii 2. Но нет.
Не знаю, что сказать... это есть, и сравнительные бенчмарки есть - рвет, просто на маленьких приложениях это незаметно.

2. Во-первых, эти 10K явно достигались не единственным сервером. Во-вторых, 4000 сервисов напихать в монолит - это ой.
Ну да, несколько десятков серверов. Может, и ой, но это работает. Несколько сотен разработчиков пишут, и денег там много.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Спасибо за ссылку. Там Symfony 4 на PHP 7.3, в которых предзагрузки нет.
Стоит сравнить с Symfony 5.1 с оптимизацией предзагрузки на php 8 с jit. Смешноожидаемо, если выигрыш по сравнению с yii будет значительным.
 

Sam Dark

Новичок
Не так. MySQL, Postgres, и скорее всего Mongo тоже, зарабатывает на поддержке проектов, которые выросли, и которым нужна оптимизация.
Oracle и Maria не страдают и не противятся MySQL в Aurora и RDS - все-равно к ним идут за помощью.
Поверь, если бы в Oracle увидели хоть намек на проблемы из-за AWS - в следующей версии был бы запрет. Даже при том, что Oracle продает свой DBAAS, они не против использования MySQL в AWS или где-либо еще.
У MySQL и Postgres рынок всё-таки весь про консалтинг, а у фреймворков не так, как и у монги. Им пришлось не так просто запускать коммерческий хостинг:

- https://www.mongodb.com/atlas-vs-amazon-documentdb/compatibility
- https://stratechery.com/2019/aws-mongodb-and-the-economic-realities-of-open-source/
- https://www.computerweekly.com/news/252455700/AWS-pushes-Mongo-DB-compatible-alternative-as-licences-change

Также и у Symfony. Cloud конкурирует с Vapor и Forge. И да, коммерчески консалтинг не масштабируется от слова совсем. Чтобы его растить, придётся стать RedHat.

Ты ж в курсе, что Skyeng, который раньше писал, что на yii, когда выросл, стал писать, что он на symfony?
Писать он стал про Symfony как только переписали большую часть легаси (и там не фреймворк причина легаси, если что). И, конечно, я в курсе. Я в этом непосредственно участвовал :)
Не знаю, что сказать... это есть, и сравнительные бенчмарки есть - рвет, просто на маленьких приложениях это незаметно.
Можно ссылку? Готовый бенчмарк мне бы очень пригодился.

Спасибо за ссылку. Там Symfony 4 на PHP 7.3, в которых предзагрузки нет.
Где ты там это увидел? Пятёрка же: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/PHP/symfony/composer.json#L12 и предзагрузка есть: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5679 (ещё в мае на это пересели).

ожидаемо, если выигрыш по сравнению с yii будет значительным.
Под восьмёрку пока Symfony никто не гонял: https://github.com/symfony/symfony/issues/37884, но я видел замеры не на синтетике, которые делал Дмитрий Стогов и нет, я не жду что JIT что-то прям радикально изменит. Особенно учитывая что рефлексия в восьмёрке стала сильно дешевле.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
теперь ты себе противоречишь, по твоей ссылке "AWS is not selling MongoDB", "AWS doesn’t have access to MongoDB",
DocumentDB - закрытая коммерческая реализация, Амазон кодом монги не пользуется, у них частичная совместимость,
компоненты симфони в ларавеле никакого отношения к ситуации Монги не имеют,
а то, что Амазон сделал конкурирующий продукт, который скушал рынок монги - да, блин, это нормально, я тоже был в проекте, который скушал Яндекс

про консалтинг я помню, конечно, на рынке iaas фреймвоки столкнулись не так давно, как я понимаю - для этого им надо стать iaas, а они (пока что) проекты по программированию, а не по operations

Где ты там это увидел? Пятёрка же: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/PHP/symfony/composer.json#L12 и предзагрузка есть: https://github.com/TechEmpower/FrameworkBenchmarks/pull/5679 (ещё в мае на это пересели).
понял, они readme.md забыли обновить

бенчмарк, например, https://kocsismate.github.io/php-di-container-benchmarks/benchmark.html
 

Sam Dark

Новичок
Нас тут интересует "Test Suite 3: Instantiating a large number of small object graphs, Singleton scope" потому как это наиболее частый кейс в реальных приложениях. И что мы там видим? 5.6ms на 1000 небольших графов (не отдельных объектов) у Yii 2, 4.4ms у Symfony. Это всё на PHP 8 с включенным OpCache, preloading и всем-всем. Выиграли мы на компиляции контейнра в очень жирном монолите 1.2ms на запрос. В % была бы норм разница если бы не абсолютное значение... Чтобы это ощутить нужно чтобы твой монолит с 4000 сервисов был написан прям совсем идеально с точки зрения производительности и раздеплоен в идеальную среду выполнения. Мы всё-таки сейчас про мысленный эксперимент или про проблемы в твоём идеальном проекте?
 

Sam Dark

Новичок
теперь ты себе противоречишь, по твоей ссылке "AWS is not selling MongoDB", "AWS doesn’t have access to MongoDB",
DocumentDB - закрытая коммерческая реализация, Амазон кодом монги не пользуется, у них частичная совместимость,
компоненты симфони в ларавеле никакого отношения к ситуации Монги не имеют,
а то, что Амазон сделал конкурирующий продукт, который скушал рынок монги - да, блин, это нормально, я тоже был в проекте, который скушал Яндекс
Да, плохой пример. Я про то, что complimentary product-ы Laravel кушают рынок complimentary product-ов Symfony, при этом у Symfony хуже позиция, они тратят силы на основные либы, а Laravel нет. У обоих основной доход не от консалтинга (насколько я знаю).
 
Сверху