Если у микросервиса написан bin/worker.php, который читает Redis или RabbitMQ, обеспечивает резолвинг и запуск хэндлеров, то почему бы нет? Ну и вообще по сути: - Apache дёргает public/index.php, в котором создаётся $app = new Web\App() со своим Router и запускается $app->handle($request). - Cron дёргает bin/app.php, в котором создаётся $app = new Console\App() со своим Router и запускается $app->handle($input). Так что изолированной бизнес-логике под контроллерами нет никакой разницы, из Apache вызов прилетел или из Cron. В Zend и Yii что там, что там пишутся почти те же контроллеры. Ну значит на этом форуме про JS-фреймворки знают больше, чем про PHP. Увы. Ну как видите, суперстар с таким же как у Вас на форуме пятилетним стажем этих знаний либо не имеет, либо показать стесняется. Так что поосторожнее, а то обидится
@ElisDN, почему бы браузер сюда не добавить? Тогда jQuery получится снаружи, если из нее послать аякс запрос.
Ещё не забудьте добавить и мышку, которой кликнули на кнопку с навешенным jQuery, который отправила Ajax-запрос.
У вышепреведённого Expressive в JS и у любого Expressive или Slim в PHP никаких БД внутри нет. И они нормально себя чувствуют. От них лишь требуется необходимый минимум в предоставлении конфигурации, маршрутизации запроса и корректного запуска нашего кода. Если вдруг будет нужна, то через yarn add или composer require подгружаем любую удобную библиотеку и дёргаем её внутри своих контроллеров или сервисов. Но самого фреймворка это уже не касается. А то, что у стандартного скелетона для Laravel в комплекте к ядру в composer.json прописана библиотека illuminate/database и десяток других – это просто для среднестатистических сайтов. Кому не нужно – тот спокойно удалит всё лишнее через composer remove. В чистом Lumen же как в Expressive тоже только ядро и никаких лишних пакетов нет. Так что стандартная поставка Laravel – это само ядро + куча доустановленных отдельных библиотек.
@ElisDN, получается, что библиотека работающая с БД - это просто библиотека, а если библиотека работает с данными запроса - то это уже фреймворк? Вам не кажется, что мы о разных потоках говорим?
Простите, что? Зачем вы приводите все эти куски кода и примеры не относящиеся к теме разговора? Мы пока что говорим исключительно о терминологии и определениях. Как и подобает в конструктивном диалоге. 1. у проекта библиотеки внутри проекта, а фреймворк снаружи проекта 2. Тот дирижёр, который бутстрапирует проект, организовывает процесс и является обвязкой запуска основного нашего кода - то и есть фреймворк. Крон находится снаружи проекта и бутстрапирует его, крон - фреймворк? Тут просто не пугаются и не падают ниц перед внедрением зависимостей и прочими rabbitmq. Я тоже так умею: докер, кубернетс, ci/cd! И? --- Добавлено --- чувак, у нас крон-демон пока что попадает в определение фреймворка. Какая бд? )
Можно и мышку, потому что она тоже вписывается в заданные условия. Тут есть два варианта: либа мышка - фреймворк, либо с определениями что-то не так.
Есть глупая штука, которая по статусу ниже нас. Которую используем и дрючим мы. Например топор или пылесос. Это управляемый нами инструмент, набор инструментов, библиотека. А есть умная штука, которая по статусу выше нас. Которая использует и дрючит нас. Например, налоговая система, которая контролирует наши финансовые потоки. Это управляющий нами внешний уклад. Каркас, в котором мы живём. Фреймворк жизни. Вот и вся разница. Что находится наверху, своими рамками определяет жизнь и под кого мы подстраиваемся, то фреймворк. Кого мы используем и держим у себя дома, тот просто инструмент. Набор классов или функций. То есть банальная библиотека функций.
Эти куски как раз относятся к теме о терминологии, какие куски PHP-кода являются библиотекой в проекте, а какие – фреймворком. Cron и мышка не находятся в скрипте. Cron не бутстрапирует проект и не запускает PHP-методы. Не несите эту тупость в массы. Cron и Apache лишь запускают процесс php. Бутстрапирует проект уже ваш код в index.php: подключает автозагрузчик, читает конфиги, создаёт фреймворковское приложение и запускает $app->run(). А оно уже дёргает нужный контроллер. Не демон, а входной PHP-скрипт, им запускаемый. А то от Вас только что выяснилось, что Cron бутстрапирует приложение. Сохраню в мегаперлы года Ну здесь настолько все всё умеют, что целый день осознать не могут, что, запущенный во входном скрипте фреймворк запускает код проекта с библиотеками. Так что попредставляю дальше, как суровые Кроны бутстрапируют просторы Большого театра...
Кто там сверху а кто снизу и кто из них управляет это к программированию вообще отношения не имеет. Нет никакого философского смысла или причин в этой терминологии. Каркас (framework) это пассивная основа целого приложения, а библиотека это пассивный набор отдельных функций. Работает только приложение. --- Добавлено --- Экзистенциальность и эскапизм.
1. MVC, предлагаемая фреймворком, не единственный правильный способ использовать такие фреймворки, как Zend и Symphony. 2. Даже если вы используете MVC фреймворка, вы можете расширить стандартное приложение, которое по-сути является лишь иллюстрацией работы с фреймворком.
@ElisDN А почему ты используешь название psr7 в своем 'фреймворке'? Кто-то ищет что связанное со стандартом а попадает на твой проект.
Без разницы. Главное – сам факт запуска фреймворковского ядра $kernel->handle($request). От нас требуются только закинуть в его роутер наши контроллеры (request handlers). А какой у нас там внутри лапшекод или MV и в каких папках – это уже наше дело. У Slim вообще стандартного примера приложения нет. Раскладывай по папкам как угодно.
Проблема в том, что вы тут пишите нам про ioc, бизнес-логику и прочие контроллеры в nodejs/http, но крон попадает под ваше определение фреймворка, не мое. Я всего лишь задаю вопрос: какого хера? Ведь есть общеизвестное определение фреймворка и туда крон не попадает, зато попадает всё что должно. Блеать, достаточно просто перевести слово на русский, даже определений не нужно ) Теперь вот добрались аж до psr-7 и его имплементаций (не, ну вы слышали? я тоже знаю умные слова). Только вот, оно то тут каким боком? PSR-7 - это всего лишь набор интерфейсов для описания http, мать его, message, к нему идет ещё несколько psr-ов комплектом. Но даже всё это вместе реализованное - не обязательно фреймворк, и обратно, фреймворк не реализовавший их, всё ещё им является. Как-то так )