devellopah
@devellopah

В чём преимущество разработки интернет-магазина на laravel по сравнению с движками?

По идее на laravel выйдет дороже делать магазин, чем на, скажем, wp+wc, ocstore или каком другом движке.
Зачем заказывать магазин на laravel, если можно тупо заказать на каком-нибудь бесплатном движке.
  • Вопрос задан
  • 8629 просмотров
Решения вопроса 1
Maksclub
@Maksclub Куратор тега Веб-разработка
maksfedorov.ru
Фрейм нужен, если цель — постоянная доработка под задачи бизнеса:
  • через 3 месяца прикрутить совместные покупки
  • через 6 месяцев прикрутить оптовую систему
  • через 9 месяцев внедрить внутренюю ЦРМ
  • через год связать с внешним коллцентром
  • через 1,5 года перевести систему с 1С на свою
  • через 2 года -- сделать 2 мобильных приложения
  • через 3 года -- внедрить партнерку и прочее
  • внедрить мультигорода с разной ценой и менеджерскими кабинетами и разными программами

... поняли вектор? Если бизнесу нужно решение задач, будет много узких и широких интеграций и изменений, если есть ИТ-отдел (или внешний, не суть), который постоянно бы работал с одной системой, то всем кодерам было бы очень глупо изучать ЦМС и костылять или ее перепахивать, особенно глупо это делать, если собираетесь брать профи... я даже не представляю "возьмем 3 мидлов и 1 сеньора и возьмем ЦМС :)"

Вот пример — целая система (опт, совместные покупки, и куча всего), где интернет-магазин лишь внешняя часть айсберга... фрейм вроде Джанго тут
и сложные сущности:
https://star-tex.ru/tkani_dlya_odezhdy/zhakkard-at...


Почти всегда нужна ЦМС
А вообще магазин и правда сейчас лучше сделать на ЦМС, если это не масштабная какая-то система... ТЕм более большое количество бизнес-задач современные системы закрывают.

Если нужно разово сделать и чутка допиливать... ЦМС подойдет, но как-только захотите сделать АПИ (как я сейчас), то 10 раз матюкнетесь (у меня выбора не было, бизнес (в котором работаю) и сейчас морально на фреймворк не готов, и бюджета нет и компетенций), и опять же — в некоторых ЦМС REST тоже уже в коробке есть

Бизнес сам поймет, когда ему не подходит ЦМС, как правило когда у руководителя компании появляется портянка бизнес-планов и задач и появляются компетенции, то фреймворк и ИТ-отдел нарисовывается довольно естественным способом.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
edli007
@edli007
full stack, team lead
А он и не нужен если функционал стандартен, он ненужен даже если функционал не стандартен, так как адеквантые движки имеют фреймворкоподобную структуру.

Этот вопрос имеет другую сторону, вопропрос кадров.
Нанимая CMS-сочника вы почти гарантировано получаете низкопробного специалиста, который практически 100% не умеет работать со встроенным в движок фреймворком а просто говнокодит код в первые попащиеся места, лиж бы работало прямо сдесь и сейчас.

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

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

Либо заплатить изначально дороже но с прицелом на доработки и нестандартный функционал, тогда скорее всего выйдет дешевле за период времени.
Ответ написан
OnYourLips
@OnYourLips
Если вам надо очень быстро сделать и забыть, и вы не планируете в дальнейшем длительной поддержки проекта и добавления значительного количества кастомного функционала - берите движок. Вы сами подстраиваетесь под него, оптимизируя свой бизнес.

Если вы хотите поддерживаемый длительное время проект и большое количество самостоятельного функционала - надо использовать фреймворк. Минимальная стоимость проекта при этом будет в десятки раз выше, но стоимость доработки в будущем - меньше.
Ответ написан
solotony
@solotony
покоряю пик Балмера
1) недостаток _всех_ магазинных движков - в их универсальности и (как следствие) - тормознутости.

2) недостаток _всех_ магазинных движков - в том что они почти никогда не удовлетворяют клиента на 100% и все-равно приходится туда лезть

3) чужой код (который ни разу не документирован) и зачастую просто кошмарен (особенно какие-нибудь модули opencart). То есть надо очень плотно влезать в изучение движка, модулей. Если вы берете "готовое решение" - это ваще пиз@#$.

Идея что вы берете готовый магазин и он из коробки начинает работать - заманчива но на практике такого не бывает, его надо пилить и пилить. То есть более-менее адекватное решение при работе с опенкартом - весь фронт сделать заново, оставить кабинет продавца.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы