Ответвление от челенджа :)
Решил я попробовать использование агентов. И для этого "теста" решил добавить усложнение взять фреймворк которые ИИ не знают. т.е. как раз вот мой. И попробовать написать к нему модуль. При этом условие: я не должен вообще ни строчки написать в нем.
В качестве функционала простейшее: генерировать аватар по нику.
Сначала взял GigaCode - он лихо начал, и быстро написал код. Я в нем видел ошибки, но такие что не сложно было бы исправить... Но вот дальше его переклинило два дня он мне выносил фоном мозг. и я просто плюнул. Был похож на вечно торопящегося джуна бросающегося переписать все каждый раз заново и забывая что делал...
Взял агента от яши. Этот уже шел медленно но очень кропотливо подходил. Постоянно возвращался к анализу фреймоврка (я ему, как и первому, сказал склонировать репозиторий фреймворка во временный каталог), и не просто перечитывал файлы но и порой использовал рефлексию для анализа. после создания очередного класса чекал синтаксис. В общем планомерно фоном сделал. (За день, но тут надо понимать, что он постоянно просил подтверждение действия, а я работал т.е. были и простои пока я увижу). В итоге сделал. И я его также попросил прикрутить стат анализ и анализ стиля кода - прогнать проверки и исправить. так же написать тесты, gitattributes и конфиг для докера (чтобы можно было использовать не только как модуль, но и как готовый сервис), а так же настроил и использовал тулзу версионирования. так же он делал своевременно коммиты ... в общем справился.
Из проблем: несколько раз в php код вставлял json (думаю это бага плагина vscode) и два раза дублировал строки когда в composer.json добавлял скрипты
Результат здесь в доке есть описание как попробовать сервис через докер :)
Ну и далее технический момент который привносит в проект использование FrankenPHP, RoadRunner и, полагаю судя по принципу, FastAPI - появлется вопросы к которым надо ответственнее относится. Я про те же утечки памяти, т.е. надо внимательнее к коду относиться, причем некоторые вещи на уровне понимания должны быть, т.к. отладить их сложнее.
Про фаст апи сам я не знаю, потому спросил у ИИ:
Так же дополню.
Для начала по самим языкам. Тут чисто по памяти в этом году видел несколько бенчей которые показали что PHP8.* быстрее чем Питон
Тыц 1 Тыц 2
Далее FastApi не совсем корректно сравнивать с CMS
Тогда надо например брать RoadRunner + фреймворк какой либо . Как вариант Laravel Octane.
Так же есть FrankenPHP. А еще есть kPHP.
Ну а далее (скажу честно лень было гуглить спросил у ИИ расклад)
кроме случаев когда сказали сделать на вп/опенкарте/цс карте/мадженто/инстант И так далее
Я например много "перевел" на опенкарт
Полагаю таки историй сильно меньше. Т.е. тут либо исполнитель страдает отсутствием заказов (в то что есть исполнители-одиночки, кто владеет всеми cms на абсолютно одинаковом глубоком уровне я не очень верю) - т.е. круг сужается. Да, конечно, можно освоить под проект (я даже плюсы под проект как то освоил), но это такие разовые частные случаи.
Я пару раз пересекался. Один раз вирус вычищал, другой данные с него забирал. Не уж то там смогли жостко ограничить все и запретить пользоваться теми или иными методами PHP :) Может быть конечно, но прям как то сомнительно... (впрочем мне не интересно - у меня по битрикс задач выше крыши, т.е. читать не буду, но вот прям по принципам построения веб CMS не верится, что нет нормальных точек расширения)
Это одна из двух основных "предъяв" в к нему в любом споре от "трупрограммистов" :)
Ну т.е. если я напишу цикл с 10 вложенными циклами где на каждом уровне будут запрашиваться данные (с сложными рандомными условиями и без ключей миллиарды записей и без кеширования) - фастапи все порешает? :)
Тут, на мой взгляд, все та же история с вопросом на сколько низкий уровень выбирать при разработке. Согласись - самый быстрый результат (в плане быстродействия работы) может дать именно "разработка с ноля" :) причем писать забив на всякие паттерны, лапшой и с дублированием кода. Универсальность это всегда дополнительные расходы. Только вот скорость разработки и внедрения....
При этом, опять же, ты считаешь прям так много проектов в реальности где этот вопрос встает ребром? Все равно важно скорость разработки, скорость внедрения, возможность сделать что то без разработчика - и это все про CMS. Причем, как правило, когда возникает вопросы быстродействия, достаточно только часть проекта реализовать выводя модуль из стандартной для конкретной CMS реализации.
Вообще я подобные споры уже проходил (и тут на Битрикс очень многие катаят, правда большинство просто "как все" не имея аргументов). И в основном когда более-менее грамотные предьявы - предъявяющий занимается в проектах чуть ли не типа ВК :) Т.е. в проектах где совсем другие критерии нагрузок, чем на среднестатистическом сайте
Да верно. Это совершенно распространенное решение. "Headless" режим. Тоже кстати, знаю потому, что к Битрикс тоже предъявляют, что он так не умеет. (хотя тоже делают, и даже не то что какие то под проект решения, а даже на маркете готовые шаблоны для ИМ есть, где фронт на ноде)
Я скажу с практической стороны. Ты (как условный seo/маркетолог) приходишь в команду и там уже есть/позовут программиста.
У него свой технический стек и он будет реализовывать на нём. Представить себе, что кто-то ему будет диктовать условия в выборе технологий и программного окружения - нонсенс.
Допустимо лишь уважительно поинтересоваться и формировать свои ТЗ уже с учётом определённой технической данности.
Поэтому тут хоть с картошечкой, хоть с макарончиками :)
Ну не все так однозначно. Я работаю с Битрикс, а уж его то еще больше обвиняют в тяжести. Теме не менее на одном из проектов есть день в году когда RPS порядка 1500 (это без учета статики). (при этом народ активно загружает файлы). Не думаю что ВП менее гибкий в этом плане. И все решается индивидуально для каждого проекта. Есть необходимость - можно подключить и другую БД, и даже не обязательно реляционную. В Битркис есть инфоблоки (это что то типа БД внутри БД управляемая из админки... это прям база, но через гибкость тормознуто. есть необходимость - выносим нужные данные из инфоблоков.
Да и в целом. мне кажется нет смысла тут спорить. Есть задача - есть решение, есть инструменты.... Профит любой CMS - скорость запуска проекта. Далее уже точечно можно расширять, менять, ускорять.
Опять же вполне себе сейчас обычным становится headless режим, где фронт вообще на ноду уезжает.
Время ответа чаще убивают уже разработчики и тут не важно фаст или слоу...... Мне как то один проект пришел (при чем для очень такой серьезной фирмы с мировым именем, дизайн там видно был прям проработанный не дешевый). так вот горе исполнитель его поручил работничку... ну и все просрали. и мне "спасай нужно за выхи добить". ... я глянул а там на главной (где к слову практически все было статикой по своей сути), 3000 не кешированных тяжелых запросов... ну каким фастом ты тут вытянешь? :D
Не. Так удобнее. При этом на части проектов еще на себя брать конфигурирования всего этого.... Не... :)
