Александр Воробьев

Недавно, как то пролетала история как "товарисч" воспользовался услугами клауде коде, но что то пошло не так и был грохнут весь проект. :)  Так что мозг, базовые знания, и бекапы - лучше не заменять на все 100% искусственному :)

PS История на правах "за что купил, за то и продаю"

Здесь сильно искажен смысл моей мысли. Я ни когда такого не говорил. Т.к. "свой инструмент" это очень широкое понятие. Я говорил только о вашем фреймворке (в том виде в котором он у меня есть). Речь шла об имеющемся на тот момент функционале. Мое представление о том, что называется фреймворк сильно отличается от вашего. И да я действительно считаю, что именно в таком виде (какой я видел) его сделать не сложно. Вот такова была моя мысль. 

Пожалуйста не искажай мои слова ;)

Очередной спринт завершился.

Пожинал плоды от пропуска этапа проектирования в проекте такого класса (в прочем много через прототипы идет все равно) - начала получаться каша из неймспейсов. По этом часть времени уделил рефакторингу, задепрекейтил пространство Core и пришел к более осознанной  структуре.

Выпустил версию 1.2 в которой из основного:

• Система конфигураций
• Система сервис провайдеров
• Служба логирования

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

Разрешаю даже каждый день туда заглядывать ;)

Какая должна быть нагрузка по вашему мнению, чтоб ощутить бяку? На нагрузке 1500 rps (без учета статики) - проблем нет (при этом была необходимость в одну очень нагруженную таблицу: читать, обновлять, писать и при этом практически нельзя кешировать. Нащупали предел - убрали ее в отдельную БД и все пошло без проблем). Более того, при большой нагрузке и если сконцентрироваться на том, что мы рассматриваем случай, когда результаты не закешированы и идет запрос в базу. В общем случае в первую очередь затыкается база, особенно если запросы на обновление присутствуют. (а если MyIASM - так там вообще легко базу заткнуть).

Как считаете для многих сайтов нагрузка в 1500 rps является обычной?

PS Да конечно, 1500 это еще не хайлоад, но хайлоад вообще живет по своим законам.

Ну существующие билдеры вполне себе справляются. У меня на первом этапе нет необходимости реализовывать абсолютно все возможности всех SQL диалектов.  По времени. Вопрос спорный и смотря с чем сравнивать.  Это все же фреймворк тоесть инструмент которому нужна гибкость. По факту я подумывал (заметь подумывал, но  в итоге так и не отрефакторил) уйти от кверибилдера только на проекте где RPS бывает до 1500 . Мой прогноз твоя история с тем как именно ты работаешь с XML будет тормозить сильно больше чем кверибилдер.  И тут может показать реальный тест: в идеале с профайлером, можно придумать иной тест и даже сравнительный :)

Опять же при грамотном подходе кверибилдеры не гоняются на каждом хите. Ну да ладно. посмотрим ;)

Ну тут такое. все зависит от сложности и логики генерации запросов.  Если количество ограниченно, и они заранее известны или тривиальны, то может быть, да и то с условием, что мы гарантированно не будем менять хранилище данных. (а это вполне себе реальная задача, у меня, например, на одном из проектов часть таблиц поехала в БД другого типа).

А так... ну представим запрос

    SELECT 
        o.id AS order_id, 
        o.total_amount, 
        o.created_at, 
        u.name AS user_name, 
        m.name AS manager_name
    FROM orders o
    INNER JOIN users u ON o.user_id = u.id
    LEFT JOIN users m ON o.manager_id = m.id
    WHERE u.status = 'active'
      AND u.city IN ('Москва', 'Санкт-Петербург')
      AND o.status != 'return'
      AND o.id IN (
          SELECT id 
          FROM orders 
          WHERE user_id = u.id 
            AND status = 'paid' 
            AND created_at > DATE_SUB(NOW(), INTERVAL 1 MONTH)
      )
    GROUP BY o.id, u.name, m.name
    HAVING COUNT(o.id) >= 1
    ORDER BY o.created_at DESC
    LIMIT 5

т.е. если тут же его реализовывать то будет так (пока только само формирование запроса)

$queryBuilder
    ->select([
        'o.id as order_id', 
        'o.total_amount', 
        'o.created_at', 
        'u.name as user_name', 
        'm.name as manager_name'
    ])
    ->from('orders', 'o')
    ->join('users', 'u', 'o.user_id', '=', 'u.id')
    ->leftJoin('users', 'm', 'o.manager_id', '=', 'm.id')
    ->where('u.status', '=', 'active')
    ->whereIn('u.city', ['Москва', 'Санкт-Петербург'])
    ->where('o.status', '!=', 'return')
    ->whereExists(function ($q) use ($queryBuilder) {
        return $q->selectRaw('1')
                 ->from('orders')
                 ->whereColumn('user_id', 'o.user_id')
                 ->where('status', '=', 'paid')
                 ->where('created_at', '>', now()->subMonth());
    })
    ->groupBy(['o.id', 'u.name', 'm.name'])
    ->havingRaw('COUNT(o.id) >= 1')
    ->orderBy('o.created_at', 'DESC')
    ->limit(5)
    ->getQuery();

и далее особенности возникают нюансы. Что если нам требуется событийная модель и запрос у нас формируется в разных местах.

т.е у нас

$query = $queryBuilder
    ->select([
        'o.id as order_id', 
        'o.total_amount', 
        'o.created_at', 
    ])
    ->from('orders', 'o')
    ->where('o.status', '!=', 'return')
    ->groupBy(['o.id'])
    ->havingRaw('COUNT(o.id) >= 1')
    ->orderBy('o.created_at', 'DESC');
Event::send(new OrderSelectEvent($query));

$query->getQuery();

И слушатели событий, если сочтут необходимым, достраивают этот запрос. Как с "готовыми" запросами такие решать задачи? А ведь это фреймворк, т.е. инструмент для решения любых задач.

Эти две недели "пожинал" плоды пропуска этапа проектирования.

Добавил в разработку статанализ, начал выводить его на максимальный уровень и понеслось : накидал себе задач, что должны быть выполнены к релизу.

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

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

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

В общем у меня все движется. Но релиза еще нет. Состояние на данный момент в ветке next

ArbNet у тебя есть движение?