Дуже цікава реалізація І такий момент. Я вже не вперше бачу спробу з Laravel зробити Symfony. Звісно такий підхід має право на життя, але в подальшому коли зміняться розробники, яким потрібно буде його підтримувати — будуть витрачати більше часу. Багато з задач, які вирішуються через розширення Query Builder, можна виконати за допомогою стандартних Scope-методів у моделях Eloquent, що є більш звичним підходом у Laravel. Відповідно, якщо був використаний в роботі більше Eloquent ORM — відпалаб додаткова потреба в використанні ше одного абстрактного шару репозиторіїв.
Загалом в кожному фреймворку є свої усталені підходи, які зазвичай спрощують роботу та підтримку проекту. Але щоразу бачу як розробники з Yii або Symfony прийшовши на проект Lavavel замість того, щоб швидко почати реалізовувати необхідний функціонал починають переписувати локіку роботи з базою даних, або починають прописувати свій роутинг і т.д. Бо на їх думку та реалізація, котра є в фреймворку з коробки порушує якісь там принципи та канони)
Те що від початку було впроваджено Events & Listeners — однозначно лайк. Це дуже виручає в подальшому.
А стосовно всіх, хто розробляє на Go, Java і так далі — Бізнесу пофіг на чому реалізовувати. Головне все зробити швидко і запустити в продакшн. Та умовна швидкість обробки запитів просто ніщо в порівнянні зі складністю/тривалістю/дороговизною реалізації. Навіть проєкти на Laravel можна гарно маштабувати.
Але реалізація однозначно класна, хоч я особисто для продукту MVP робив би простіше і тільки після підтвердження потипу його апдейтив, скоротивши час запуск ше на 3-4 тижні
Дуже цікава реалізація
І такий момент. Я вже не вперше бачу спробу з Laravel зробити Symfony. Звісно такий підхід має право на життя, але в подальшому коли зміняться розробники, яким потрібно буде його підтримувати — будуть витрачати більше часу. Багато з задач, які вирішуються через розширення Query Builder, можна виконати за допомогою стандартних Scope-методів у моделях Eloquent, що є більш звичним підходом у Laravel. Відповідно, якщо був використаний в роботі більше Eloquent ORM — відпалаб додаткова потреба в використанні ше одного абстрактного шару репозиторіїв.
Загалом в кожному фреймворку є свої усталені підходи, які зазвичай спрощують роботу та підтримку проекту. Але щоразу бачу як розробники з Yii або Symfony прийшовши на проект Lavavel замість того, щоб швидко почати реалізовувати необхідний функціонал починають переписувати локіку роботи з базою даних, або починають прописувати свій роутинг і т.д. Бо на їх думку та реалізація, котра є в фреймворку з коробки порушує якісь там принципи та канони)
Те що від початку було впроваджено Events & Listeners — однозначно лайк. Це дуже виручає в подальшому.
А стосовно всіх, хто розробляє на Go, Java і так далі — Бізнесу пофіг на чому реалізовувати. Головне все зробити швидко і запустити в продакшн. Та умовна швидкість обробки запитів просто ніщо в порівнянні зі складністю/тривалістю/дороговизною реалізації. Навіть проєкти на Laravel можна гарно маштабувати.
Але реалізація однозначно класна, хоч я особисто для продукту MVP робив би простіше і тільки після підтвердження потипу його апдейтив, скоротивши час запуск ше на3-4 тижні