Интернет-магазин на js фреймворке. Реально?

Аватар пользователя digital_sword digital_sword 7 июня 2020 в 7:45

Например фронтенд на react или vue, бэкенд тоже на js, strapi например.
Реально - имеется ввиду не теоретическая возможность, а то что кто-то это делал, это имеет смысл, это по ряду причин лучше чем opencart или подобные cms.

Пусть без систем оплаты, без интеграции с 1с...

И насколько это трудозатратно по сравнению с хорошо настроенными, темизированными , сверстанными с дизайна опенкартами? (То есть не коробочная версия опенкарта, где поставил что есть и залил шаблон, а именно честная full разработка)

Комментарии

Аватар пользователя gun_dose gun_dose 7 июня 2020 в 20:06
2

На бэкенде можно и друпал поставить. Что касается фронта - чисто субъективно на js фронт делать приятнее, чем верстать с нуля тему под друпал. Кроме того всякие сложные формы, всплывашки и т.д. на том же реакте делать значительно удобнее, чем на друпал. Но простой дизайн на друпале будет быстрее сделать. Чем сложнее интерфейсы, тем больше ощущается профит от js-фреймворков.

Но это конечно, если умеешь. Если не умеешь, то надо хотя бы месяц учиться, чтобы тебе могли доверить делать хоть что-то. И где-то полгода надо учиться, чтобы начало получаться что-то вменяемое.

Аватар пользователя adubovskoy adubovskoy 7 июня 2020 в 23:22

А у меня общий вопрос к топикстартеру

Какие проблемы решает и зачем?

Рендерить на клиенте? Для магазинов очень хотелось бы в SEO. Делать ssr - а в чем тогда основной профит?

вот если это для оптовой торговли например SPA, где привлечение оффлайн и им сео не нужно, там да, можно делать

Аватар пользователя adubovskoy adubovskoy 8 июня 2020 в 1:27

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

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 6:54
1

Касаемо интернет-магазинов, на клиенте надо хранить только корзину и возможно пересчитывать какие-то персонализированные скидки. Вообще не вижу проблемы обновлять это на клиенте, а с бэка отдавать страницу, как для анонима.

В итоге я бы сказал, что трудоёмкость создания сайта на next.js по сравнению с обычным реактом возрастает всего процентов на 10.

Аватар пользователя digital_sword digital_sword 8 июня 2020 в 7:48

1. с сео особых проблем там нет уже сейчас , и тенденция к улучшению.
2. нужно разбираться только в js и все
3. опенкарт он не беспроблемный. Некоторые казалось бы простые в друпале вещи по настройке полей и вывода решаются супер сложно. Некоторые тяжелые вещи просто нельзя убрать (максимум это форму заказа обычно на симплу меняют), а часто нужен простой магазин
4. тренд

Аватар пользователя webcrf webcrf 8 июня 2020 в 8:32

digital_sword wrote: Например фронтенд на react или vue, бэкенд тоже на js, strapi например.
Реально - имеется ввиду не теоретическая возможность, а то что кто-то это делал, это имеет смысл, это по ряду причин лучше чем opencart или подобные cms.

Не понимаю как можно сравнивать такие вещи.
У опенкарта куча функционала, с тестами, с поддержкой сообщества, хостится где угодно.

А что ваш самописный сайт на js везде:
1) какой вы там функционал сможете собрать, большой вопрос. Явно не такую развитую вещь как Drupal Commerce. А тесты напишете к коду?
2) Кто такой сайт сможет поддерживать, где js с его фреймворками и там и там
3) Где хоститься будет, явно ж не шаред, то же еще один момент

А лучше в том что
а) user experience без перезагрузки
б) типа нагрузка на сервер уменьшается?

Насчет a) так я бы тут сказал что со всем этим SPA подходом очень многое умалчивается.
Какую например часть приложения все таки программируют на том же Vue/React?
Только ли UI, удобное взаимодействие с пользователем, или какую то логику туда то же протягивают.
Видно как в мануалах по Vue они склонны к серверу чисто за данными через api гонять, но все бы хорошо, но код то в браузере никак не защищен от вмешательства.
И сам же подход с работой с бэком через REST API тоже специфичный, состояние то REST не сохраняет.

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 11:59

Где хоститься - это вообще не проблема. Если у заказчика есть деньги на разработку на js, то хостинг под это будет вообще раз плюнуть.

Аватар пользователя webcrf webcrf 8 июня 2020 в 13:09

1) А что разработка на js такая дорогая по сравнению с разработкой на drupal? В друпале наоборот можно зачастую пробродить впустую, время протратить, пытаясь функционал собрать, а оно не получится.
2) Я больше не про хостинг, а про поддержку, требование наличия сисадмина, если там будет VPS. Это же сразу уже усложняет все владельцу, это не админка где то на хостинге

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 13:17

1) Да, там цены выше в 3-4 раза со старта. Хотя конечно если проект реально сложный, то на js может оказаться и дешевле, чем чисто на друпале, но это в случае, если реальная (не завышенная) стоимость разработки будет от 5к$.
2) Не надо там ничего сисадминить. Запустил ноду, поставил в крон перезапуск раз в N дней и всё.

Аватар пользователя webcrf webcrf 8 июня 2020 в 15:36

2) Да там в реалиях не одна нода то будет.
И нжинкс и БД и Redis т.п.
После пары разрабов, которые что то поруются под свои задачи, такие проекты мне напоминают каких то больных животных, где даже на уровне ОС нельзя гарантировать что все окей/безопасно настроено.
Это если еще сайт не начнут специально кумарить/ломать.

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 15:42
3

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

Аватар пользователя webcrf webcrf 9 июня 2020 в 6:06

Ну я ж об этом и говорю, сайт с поддержкой от студии, с услугами сисадмина - это совсем другое дело, в т.ч. по финансовым затратам.
Да и привязочка, в случае node.js на беке, к студии будет неслабая.
Но уж никак вариант когда заказчику отдали такой сайт и он уже с ним как то сам, как это в цмс-ках обычно.

Аватар пользователя gun_dose gun_dose 9 июня 2020 в 7:11

Ну да, это полностью другой ценовой сегмент с другими клиентами, другими исполнителями и другими проектами. К слову, это ещё одна причина изучать js.

Аватар пользователя marassa marassa 8 июня 2020 в 10:24

gun_dose wrote: Касаемо интернет-магазинов, на клиенте надо хранить только корзину

Полный офф, конечно, но корзина на клиенте - это не самый лучший UX. Волею судеб, уже третий месяц раз в 7-14 дней заказываю продукты с доставкой из Перекрестка. Привык к тому, что вспомнив что еще нужно купить вдали от компа, прямо с мобилы захожу на сайт перекрестка и кидаю нужный товар в корзину. Потом через неделю, когда пора уже заказывать, сажусь за комп, вижу в корзине всё, накиданное туда с телефона и планшета, добавляю еще и заказываю.
К хорошему быстро привыкаешь, и когда я в каком-то другом магазине захожу в корзину и не вижу там товара, который туда вчера положил на планшете, это уже бесит Wink

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 11:58

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

Ну и кстати, если корзина и на бэке, всё равно нет никакой нужды рендерить её на бэке через SSR, а можно вытаскивать асинхронно уже после загрузки основной страницы.

В общем, все эти проблемы с регидратацией не так уж и сложны.

Аватар пользователя Punk_UnDeaD Punk_UnDeaD 8 июня 2020 в 15:53

если всё сделать по уму, то будет отлично работать и отдавать основные куски из кеша анонима
а если нет, то нет

Аватар пользователя digital_sword digital_sword 8 июня 2020 в 10:45

спасибо, ясно, что это не вариант. По варианту js+js вопрос снят.
Если брать laravel+react тоже понятно, это работает.

А если как в начале темы gun_dose посоветовал drupal+react? Или это будет костыль. https://yadi.sk/i/RwxIbKIcx1SedA или что-то изменилось, и это сейчас вполне себе осуществимо?

marassa wrote: Полный офф, конечно

нет, как раз таки прямо в тему.

Аватар пользователя webcrf webcrf 8 июня 2020 в 13:20

Вопрос тут - что вам надо.
1) Если вам нужна навороченная админка, по возможностям.
То у друпала традиционно очень все сложно организовано на уровне БД.
Поэтому если придется для такого API делать, явно тут какие то должны быть уже друпальные решения.
2) Но если всех этих наворотов не надо, то простую админку , как и API, можно довольно не трудно собрать на ларе/yii

p.s. А куда вы "отлучались на 5 лет"? Вообще из программирования или из веба?

А так то вот эти vue приложения - это ж по сути статический один большой js скрипт, который аяксом из апи нужные данные подтягивает, т.е. он от бэка не зависит и последний может быть любой.

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 13:23

Что тогда, что сейчас друпал из коробки готов к использованию в качестве бэкенда для js-фронта. Мало-мальски рабочий бэкенд вообще можно накликать тупо мышкой, поставив всего 2-3 модуля. Если хочется что-то более сложное, чем предлагают модули REST и JSONAPI из ядра, то апи друпала позволяет очень легко создавать любые эндпоинты под любые цели.

Статей, "как подружить vue + drupal" можно и не найти. Но статей, как использовать друпал в качестве бэкенда для чего-либо - полно.

Аватар пользователя webcrf webcrf 8 июня 2020 в 13:44

Тут вопрос - API над какими сущностями это будет?
В друпале же все вокруг нод крутится, а у них там кучи служебных полей, переводы и ревизии и куча всего остального, и вот это все из админки автоматом в API пойдет.

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 14:03

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

Кроме того, никто не заставляет отдавать в апи абсолютно все поля сущностей.

Аватар пользователя webcrf webcrf 8 июня 2020 в 15:44
1

Restful API - это довольно шаблонная вещь, на которую есть полно заготовок, а в php фреймворках и генераторов.
Вот и вопрос - зачем ради такой вещи ставить целого монстра как друпал. Только потому чтобы без php программиста? Это священная цель?
При этом пойдет что то уже дополнительное, нестандартное, друпал первым начнет палки в колеса ставить.
Так что я не вижу смысла чтобы из пушки по воробьям.
Ладно бы действительно админка когда нужна с кучей управления контента, но вот эти SPA приложения - они же статические по сути, т.е. идут вразрез тому с чем всегда работал друпал, когда в нем что то делаешь и это отражается на фронте и бэке, т.к. это суть одно.

Аватар пользователя gun_dose gun_dose 8 июня 2020 в 16:05
1

Мы тут говорим не про SPA, а про интернет-магазин. В любом случае нужна админка для администрирования товаров и заказов, и друпал тут очень хорошо вписывается. Можно конечно админку тоже сделать на реакте, но это как минимум вдвое увеличит трудоёмкость.

Аватар пользователя webcrf webcrf 9 июня 2020 в 6:00

Админку можно на yii2 сгенерировать, простые страницы круда.
Что увеличит трудоемкость - это друпал на бэке, когда фронт на js из этого друпала будет юзать десятую процента от архитектуры

Аватар пользователя gun_dose gun_dose 9 июня 2020 в 7:18

На yii админку надо генерировать, а на друпал она сразу есть - где трудоёмкость то? Тем более уверен, что автоматом форма для товара с несколькими вариациями ни одним фреймворком не сгенерируется.
Если фронтенд не юзает часть архитектуры - что в этом плохого? Опять же часть архитектуры заюзает админка. Хотя бог с ней с админкой, давай лучше перечисли, что входит в те неиспользуемые 90% архитектуры, кроме темизации и блоков?

Аватар пользователя webcrf webcrf 9 июня 2020 в 10:30

Вот я чет совсем не уверен что коммерц вываливает свое rest api, по которому с ним можно работать с фронта.
Недолгое гугление показывает что если с корзиной, через доп модуль, еще что то есть, то чуток в сторону, уже пошла скачка.
А ведь с фронта и зарегаться надо и там и на апи, и чекаут и личный кабинет, и все под архитектуру коммерца...

Аватар пользователя gun_dose gun_dose 9 июня 2020 в 10:48

Я под проект написал своё апи, сайт уже работает второй год, никаких проблем. В том числе с интеграцией с платёжными системами и мультивалютностью. Регистрироваться кстати в коммерсе не обязательно. А что такое "личный кабинет под архитектуру коммерса" - мне вообще непонятно.

Я делал уже 5 разных проектов, где друпал выступает бэкендом для реакта, и прекрасно понимаю, о чём говорю. С твоей же стороны только и слышно "я думаю, я не думаю, мне кажется, я не уверен".

Аватар пользователя webcrf webcrf 9 июня 2020 в 12:38
1

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

Аватар пользователя gun_dose gun_dose 9 июня 2020 в 13:43

Во-первых, если анонимный пользователь может сделать заказ, это не означает, что это не может сделать зареганый пользователь.
Во-вторых, я прекрасно знаю, что такое личный кабинет, и он даже есть на моих сайтах.
В-третьих, ты изначально завёл речь не о личном кабинете, а о каком-то "личном кабинете под архитектуру коммерса" - вот что это такое, и чем оно отличается от личного кабинета любого другого интернет-магазина, я не знаю.