Как спроектировать архитектуру небольшого сервиса, обновляющего данные на сайте?
Проект на laravel. Хочется по умному спректировать его чтоб он выполнял следующие задачи:
- считывание архива с yaml файлом со стороннего сервера
- распаковка архива
- считывание данных из архива в таблицу.
Понятно, что можно создать artisan команду и запускать ее по расписанию и она будет всё это делать.
Но хотелось бы красиво всё сделать, используя принципы Solid и возможно подходящие для задачи патерны.
Как я это вижу:
запускаем job по расписанию, которая бы запускала первый сервис:
1)Сервис, отвечающий за получение данных с сервера. Он должен считать файл и положит его в нужную папку и запустить
следующую job.
Вторая job будет вызыват сервис, занимающийся распаковкой данных и запускать следующую job
Третья job будет считывать данные из файла и помещать их в базу таблицу базы данных и запускать следующую job
Четвертая job будет подметать за собой - удалять распакованные файлы, удалять архив.
ервисы должны будут быть связаны между собой при помощи DI (там, где нужно) и наследоваться каждый от абстрактного класса
с той задумкой, что алгоритм считывания прайса может меняться в зависимости от, к примеру, поставщика.
Так же способ разархивации тоже может меняться.
Могут меняться и поля в прайсе, а значит мы должне создать тоже абстрактынй класс, где будут приведены обязательные поля для всех прайсов,
а у классов, унаследованных от этого класса будут уже еще дополнительные свои специфицеские поля в зависимости от поставщика.
Можете прокомментировать данный подход или предложить более правильную идею?
Я еще подумываю над тем, чтобы создать доп. таблицу, в которой будет отражаться состояние выполнение общей задачи и ее статус и количество попыток.
Чтоб если по расписанию положено было заново запустить воркеры, то чтоб они смотрели выполнилась ли успешна предыдущая группа задач.
Повторю гипертрофированный пример из ответа: по вашему обновление цены и названия это разная ответственность? А у продукта ещё 1000 параметров бывает. Под каждый будете микросервис пилить? Бред же полный
aleksejjjjj, ну вот смотрите. у нас в маркет плейсе много поставщиков и у каждого может быть прайс в отдельном формате. Напрашивается же общий интерфейс и потом для каждой реализации свои особенности - это касается и алгоритма обработки прайса в первую очередь.
или вы предлагаете написать код, где будет куча разных if ?
Слава, возможно в будущем, ваш сервис настолько крут получится, что его добавят в миссию на марс.
Обязательно заложите такую надёжность в ваш код и ещё тестами покройте всё.
По существу вы вобще, нет ВОБЩЕ не понимаете то, о чём написали.
Начитались кучу статей и пытаетесь это как-то применить.
Делать надо то что умеете и учиться потихоньку. Шаг за шагом по каждой ступеньке.
А не пытаться прыгнуть сразу через 100.
Когда у вас встретятся задачи где нужно то, что вы пишите, тогда поймёте где это надо применять, а где нет.
Jobs вобще по сути нужны для того, чтоб обеспечить надёжность действия и его обработку в случае ошибки. Или вывести операцию в другой поток. Или распределить нагрузку, распараллелить форыч например.
И всё это вместе.
Вам даже это не очевидно.
Да жестко, но это так. Все через это проходят :)
ну от lara-вельщиков ничего другого ожидать и не следовало. Кроме MVC ничего не понимают и шире думать не хотят. Я уже лет 8 назад делал подобные сервисы, а говорите, что я не понимаю. А вы и дальше продолжайте пихать всё в одну функцию и писать лапшеобразный код.
Слава, Слава, кому ты тут в уши заливаешь? Если ты забыл, то тут все твои вопросы видны, по ним уровень твоей «компетенции» определяется влёт. И если ты «уже лет 8 назад делал подобные сервисы», то зачем вопросы? Бери и делай.
JhaoDa, раньше я делал так как мне хочется - лишь бы работало. А сейчас у меня этап, когда я делаю как мне хочется, но при этом пытаюсь изучить как нужно писать правильно с точки зрения архитектуры.
Мои примитивные воркеры которые я написал много лет назад до сих пор работают как часы, хотя они не использовали весь функционал, который был предоставлен очередями даже в те годы. Но зато как часы.
Но если я показал бы кому-нибудь этот код из потенциальщиков, то не прошел бы собеседование. Пэтому сейчас я насилую тостер чтобы выудить у специалистов как можно больше информации на предмет как делать правильно вне зависимости от того есть у меня решение или нет его.
JhaoDa, плюс тебе самому не стыдно признаваться, что ты о человеке судишь по его постам в интернете? нет ничего глупее. Это так же как судить о человеке по мемам, которые он выкладывает у себя на стене или по его твитеру или по его фоткам из инсты.. Человек может прекрасно знать что он делает и как это делать, но на подобных форумах притворяться простачком и писать вопросы в провокационном стиле чтоб не оставить равнодушными таких душных как ты персонажей. Плюс за моим аккаунтом раньше сидел целый отдел тех поддержки - в этом и в другом аккаунте.
А сейчас у меня этап, когда я делаю как мне хочется, но при этом пытаюсь изучить как нужно писать правильно с точки зрения архитектуры.
Слава, Я и написал, что все через это проходят, это нормально.
Когда придёт понимание, что нужно делать архитектуру легковесную, необходимую, тогда и пропадёт желание делать перезаклад в 10 раз.
это именно и будет Построение архитектуры.
Кстати, в стройке, в архитектуре зданий то же самое.
Там порой делают огромный перезаклад прочности, огромные колонные, огромные балки, но тонкие другие месте - горе архитекторы. Если такие здания в итоге строят, то получается в несколько раз дороже, чем правильно рассчитанное здание с той же прочностью.
Отличие в программировании в том, что код может расширятся.
Но тогда то, что не ожидается изначально, не нужно закладывать заранее.
А когда нужно добавлять, обязательно нужно делать рефакторинг. По моему опыту обычно меняется не более 10% функционала. поэтому делать перезаклад на остальные 90% не нужно.
Вобщем архитектура, это не перезаклад, а оптимизация кода и ресурсов на этот код.
Я еще подумываю над тем, чтобы создать доп. таблицу, в которой будет отражаться состояние выполнение общей задачи и ее статус и количество попыток. Чтоб если по расписанию положено было заново запустить воркеры, то чтоб они смотрели выполнилась ли успешна предыдущая группа задач.
в job-ах уже есть все это. нужно только научиться применять. Вам не нужен никакой Job. Job вам пригодился бы если вам нужно было бы по каждому офферу ходить куда-нибудь да чего-нибудь от туда ждать, то тут несомненно пригодилось бы. А так какой смысл их? Для начала выпилите все в сервисы.
ну это тестовая задача просто на знание возможностей ларавел и на способность проектировать, а не писать сервисы-однодневки, которые потом пришлось бы переписывать полностью появись еще один донор.
Простой
Простой
