Бесплатный движок магазина на React + NodeJs + MongoDB!

[vamshop]

Добавлен голосовой поиск.

[vamshop]

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

 

Причём бесплатно, без внешних подключений к каким-либо api.

 

Технически всё сделано через Web Speech Api.

 

Web Speech API везде поддерживается, где есть хром движок (а это, в том числе, и яндекс.браузер и новый ie, т.е. считайте все браузеры поддерживают кроме firefox).

 

Это и смартфоны, и планшеты, и телевизоры, и компы, и ноутбуки, любые устройства.

 

Интересно именно добавить его на любой сайт, т.е. распознавание голоса в текст и сразу идёт поиск по интернет-магазину.

 

Русский распознаётся отлично, вообще без ошибок, очень круто.

Змінено 3 січня 2020 користувачем vamshop

[MersaMatruh]

...

Змінено 6 січня 2020 користувачем MersaMatruh

[Pirks]

Тема eCommerce c nodejs мне тоже  интересна.
Пробую node в локальных проектах - парсинг (puppeteer) , консольные обработчики и т.д. Посматриваю и на headless CMS, например strapi - выбираю, что попробовать если не для полноценного магазина, но для  создания админки для работы с MySQL OpenCart.  
Все интересно, но смущает один момент - NoSQL. Еще не пробовал, поэтому вопрос.
Как MongoDB себя чувствует в таких например задачах, как хранение нескольких прайсов в одной таблице ( ~300 тыс.  записей), когда я одним запросом получаю оптимальную цену для каждого товара с учетом приоритета прайса и срока поставки. Все в одном запросе.     
Какие преимущества в ИМ у MongoDB перед реляционными СУБД ?

[vamshop]

Лично я с большими базами MongoDB дел ещё не имел пока что, для меня тоже MongoDB новая база.

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

 

Вот есть статья про сравнение mysql и mongodb - https://habr.com/ru/post/322532/

 

Там хорошие примеры кода.

 

imho, основное - это формат данных - json

 

Раз весь проект на JavaScript и всё описывается в json формате, то логично и базу данных тоже использовать, которая изначально работает в json формате, просто так удобнее.

 

Единообразие кода.

 

Другой удобный момент MongoDB применительно к веб-сайтам, движкам, которые берутся за основу своих разработок, это так называемая schemaless база данных, т.е. отсутствие необходимости изначально создавать структуру таблиц, это добавляет гибкости в работе и это очень удобно если процесс изменений сайта, базы постоянный, постоянно добавляется таблицы, новые колонки в таблицы и т.д., очень удобно всё без необходимости добавлять/менять структуру таблиц.

 

В целом, в принципе, сейчас всё одинаково, по большому счёту, без разницы, sql, nosql. Для не сильно сложных проектов вообще не принципиальный вопрос, лично моё imho, какая база данных. Тут больше вопрос в удобстве и MongoDB отлично дополняет набор из api центричности, 100% js кода, react кода, т.е. MongoDB не выглядит каким-то инородным кодом внутри проекта со своим sql синтаксисом, как это было бы в случае с mysql.

 

Те же таблицы (коллеции), те же индексы в таблицах, те же запросы в базу insert, update, delete.

 

Просто в MongoDB всё это сразу идёт в json формате, запросы и ответы, без необходимости заранее определять структуру таблиц, полная свобода действий, ты просто не думаешь о базе своей, а занимаешься кодом, развитием проекта. Это очень удобно, особенно в случае api-центричного веб-приложения, когда постоянно добавляются новые методы в api, добавляется новая функциональность на сайт. Ты занимаешься именно развитием сайта, а не постоянными раскопками в таблицах, схемах таблиц, смотришь, а что можно записывать в эту колонку, можон ли сюда текст писать или только числа, влезет ли в колонку большой текст с описанием товара, или не влезет, и придётся лезить в базу данных и менять, к примеру, тип колонки с TEXT на LONGTEXT, что б всё поместилось, нужно чот-то добавить новое - опять придётся лезть с базу, добавлять тут колонку, добавлять там колонку, добавлять тут таблицу и т.д.

 

В MongoDB просто нет в этом необходимости, сразу пошёл писать код и сразу же всё появляется в базе, и новые колонки и новые таблицы.

 

Очень удобно, на самом деле.

 

Змінено 7 січня 2020 користувачем vamshop

[Pirks]

Прочитал статью на хабре и еще более утвердился, в том, что мне ближе SQL подход в проектах ИМ.
И сам строгий подход к проектированию архитектуры данных, это тоже мое. ) 
Очевидно у нас с вами разный подход к решению подобных задач. )
Кстати, с учетом того, что в последних версия mySQL можно хранить и делать запросы  JSON, мы можем использовать mySQL как noSQL - запихать кучу всего в одно поле типа JSON.
Надо пробовать! 
 

[vamshop]

Ну да, кому что больше нравится, это, по большому счёту, не приципиально.

Лично мне очень понравился именно MERN стэк, т.е. MongoDB + Express.Js + React + NodeJs, вот при таком инструментарии всё очень единообразно и органично выглядит, как во frontend'е, так и в backend'e.

[Yoda]

1 час назад, vamshop сказал:

Ну да, кому что больше нравится, это, по большому счёту, не приципиально.

Лично мне очень понравился именно MERN стэк, т.е. MongoDB + Express.Js + React + NodeJs, вот при таком инструментарии всё очень единообразно и органично выглядит, как во frontend'е, так и в backend'e.

 

Скажите, а зачем вы эту дичь вашу сюда занесли?

 

[Pirks]

22 часа назад, Yoda сказал:

 

Скажите, а зачем вы эту дичь вашу сюда занесли?

 

Вроде в курилке можно обсуждать любые темы ...
Или разговоры на темы технологий альтернативных  OpenCart здесь запрещены?

[vamshop]

Про простое и удобное оформление заказа в cezerin.

В cezerin сделано максимально простое и удобное оформление заказа, управляемое из админки.

Какие задачи были решены:

1. Максимально не напрягать посетителя при оформлении заказа.

2. Привязать поля с данными о доставке не к общей форме, а к модулям доставки.

3. Всё работает на react + api, без перезагрузок страницы в браузере.

Например, я доставляю только по городу.

Зачем мне заставлять покупателя указывать почтовый индекс, страну, регион.

Я просто в форме оформления заказа отключаю все поля (через Админку -  Настройки - Оформление заказа), оставляю только 2 поля - Имя и Телефон.

Всё.

Дальше уже на выбор покупателя.

Если выбирает доставку по городу, то при выборе доставки появляются поле Адрес, Метро и т.д.

Вот выбрал доставку курьером, появилось поле Адрес

При выборе доставки почтой - появляются поля Адрес,Индекс.

 

У Вас есть возможность быстро и удобно выводить поля формы в зависимости от выбранной доставки.

Всё это настраивается в Админке - Настройки - Доставка.

В разделе Поля оформления заказа.

Вот пример для модуля курьерская доставка:

Вот пример для модуля доставки почтой:

 

Кроме того, Вы можете ограничивать модули доставки в зависимости от указанной страны, города, региона.

В зависимости от суммы заказа, либо от веса заказа.

 

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

А не так как обычно, что нужно заполнить кучу форм с десятками полей, условий.

 

Всё быстро, просто и удобно.

Змінено 26 січня 2020 користувачем vamshop

[vamshop]

Добавлен новый модуль - Facebook Messenger.
Виджет facebook чата, встраивается на сайт, а-ля jivosite.

 

Настраивается в Админке - Приложения.

[vamshop]

Небольшая демонстрация реально работающего магазина на базе Cezerin.

 

https://plasha.ru

 

PWA магазин, никакого PHP, MySQL, никаких монолитов.

 

Полное разделение frontend и backend.

 

100% на JavaScript: и Frontend (React + API), и Backend (NodeJS).

 

API-центричное веб-приложение на микросервисах.

 

Современный дизайн на базе Figma.

 

Обратите внимание, как быстро работает сайт.

 

Например попробуйте фильтр по цене на странице - https://plasha.ru/kategoriya-3

 

Попробуйте подгрузить больше товаров кнопкой Показать ещё на странице.

 

Посмотрите в консоли разработчика в браузере хром, как всё выглядит и как работает. 

 

В отличии от OpenCart, нет лишних запросов и прорисовок.

 

Через API получаем "сырые" данные в JSON формате и отрисовываем их в React.

 

Попробуйте поиск товара.

 

 

Змінено 13 лютого 2020 користувачем vamshop

[Pirks]

vamshop, направление JAMstak смотрели?
Что скажете, какое впечатление?

[vamshop]

On 3/2/2020 at 10:00 AM, Pirks said:

vamshop, направление JAMstak смотрели?
Что скажете, какое впечатление?

 

Я всеми руками за.

 

и если честно, не до конца понимаю, почему у нас так мало используются современные веб-приложения, с раздёлнным backend, frontend, практически не вижу jamstack сайтов.

 

Почему-то мы ещё в каменном веке живём с битриксами, opencart'ами.

 

Например вот раздел с документацией https://cezerin.org/docs

 

Это как раз можно сказать JAMStack, не совсем конечно, контент не через api приходит, а просто из markdown страниц git репозитория, но, по сути, это тот же api.

 

т.е. есть markdown файлы - https://github.com/Cezerin2/cezerin2.github.io/tree/master/docs

 

и есть JS, который всё это оформляет в более-менее приличный вид и через github pages https://cezerin.org домен привязан к репозиторию этого с документацией.

 

В итоге и получается https://cezerin.org/docs

 

Используется docsify - https://docsify.js.org/

 

и получается более-менее прилично оформленная страница https://cezerin.org/docs

 

Ну про jekyll я думаю тоже многие знают.

 

 

Змінено 3 березня 2020 користувачем vamshop

[Bn174uk]

В 03.03.2020 в 20:43, vamshop сказал:

и если честно, не до конца понимаю, почему у нас так мало используются современные веб-приложения, с раздёлнным backend, frontend, практически не вижу jamstack сайтов.

Так уже говорили и обсуждали это, что такие сайты дорогие в обслуживании.

 

В 03.03.2020 в 20:43, vamshop сказал:

Почему-то мы ещё в каменном веке живём с битриксами, opencart'ами.

 

Вот как только эти технологии станут по цене разработки такие же как и эти движки + комьюнити будет такое же большое, тогда люди и перестанут жить в каменном веке.

 

 

 

[Pirks]

В 04.03.2020 в 22:44, Bn174uk сказал:

Так уже говорили и обсуждали это, что такие сайты дорогие в обслуживании.

Вот как только эти технологии станут по цене разработки такие же как и эти движки + комьюнити будет такое же большое, тогда люди и перестанут жить в каменном веке.

 

Про стоимость поддержки соглашусь, но обратите внимание на рынок Landing Page. По моим наблюдениям, на фрилансе 80% заказов по LP, это настроить и доделать LP на конструкторах - генераторах. Мне кажется такое может случиться и с ИМ в ближайшие два-три года. 
Нет, это не  магазин как сервис в облаке. А магазин собранный из услуг, таких как serverless или FaaS. 
Например, что мешает тому же  cezerin ) обращаться не к API своего бэкэнда, а к API ресурса, где будут храниться товары? 
С возможностью быстрой фильтрации, масштабирования и бэкапов. Здесь даже админы - DevOps не нужны, например для оптимизации баз данных.

И админка, для управления товарами, экспортами - импортами, ценообразованием, тоже может быть как отдельный сервис.
И сама бизнес модель получается рентабельной, на serverless оплата идет за обращения к API или базам данных. Т.е. сайт не пользуется популярностью, нет запросов к API соответственно оплата за услуги падает.
З.Ы.Это не прогноз, это ощущения от прочтения некоторых материалов на тему ... )

  

Змінено 7 березня 2020 користувачем Pirks

[vamshop]

 

Quote

З.Ы.Это не прогноз, это ощущения от прочтения некоторых материалов на тему ... )

 

Ничего не мешает.

 

Этим и интересен подход к полному разделению frontend и backend и работа чисто на API запросах к backend'у, к внешним сервисам, уход от монолита.

С монолитом типа OpenCart провернуть такое будет сложно, получится что-то вроде скрещивания ужа с ежом.

Не избавишься в полной мере от недостатков монолита и не получишь в полной мере достоинств микросервисов.

 

Но конечно нужно сообщество, без людей, без интереса со стороны сообщества сложно что-то сдвинуть.

Вот пытаюсь как-то привлечь людей к этой теме.

 

Когда у тебя всё общение с данными (со своим backend'ом, либо с внешними сервисами любыми) через API запросы,  то рисовать можно что угодно, где угодно и как угодно.

Не нравится React, бери Vue, Svelte и т.д. Это никак не повлияет на твой backend, твой api, т.к. он независим от внешнего представления, frontend'a.

Змінено 7 березня 2020 користувачем vamshop

[vamshop]

Кстати, на searchengines тоже интересная тема появилась, на medium об этом тоже писали как-то статьи.

Магазин, сайт на гугл таблицах.

 

В качестве данных для магазина выступают таблицы excel.

+ обычный клиентский html + css + js на стороне сайта, без необходимости серверной части вообще.

 

Это тоже ведь возможно благодаря API гугл таблиц, не было бы доступа к "сырым" данных таблиц через api, ничего такого сделать нельзя было бы.

 

Вот тема - https://searchengines.guru/showthread.php?t=1028862

Пример - https://tiddlywiki.ru/

http://luckysushi.ru/habarovsk/heeg.html#index

 

т.е. все данные и формулы в таблицах.

 

Получается даже хостинг не нужен.

 

Backend - это гугл таблицы.

Frontend - можно разместить например на github pages, и привязать домен к github pages.

т.к. клиентская часть без серверной части, должно работать напрямую с github.

 

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

Зачем таким магазинам битрикс или opencart, wordpress+woocommerce.

 

Просто собирай заказы и работай, занимайся рекламой, продвижением.

 

и опять же, т.к. всё на API запросах, можно сразу направлять все заявки из гугл таблиц например в Битркс24, AmoCRM.

 

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

 

 

Змінено 7 березня 2020 користувачем vamshop

[Pirks]

В 07.03.2020 в 11:04, vamshop сказал:

Кстати, на searchengines тоже интересная тема появилась, на medium об этом тоже писали как-то статьи.

Магазин, сайт на гугл таблицах.

 

В качестве данных для магазина выступают таблицы excel.

+ обычный клиентский html + css + js на стороне сайта, без необходимости серверной части вообще.

 

Это тоже ведь возможно благодаря API гугл таблиц, не было бы доступа к "сырым" данных таблиц через api, ничего такого сделать нельзя было бы.

 

Да, я в теме API Google Spread Sheet. Активно пользуюсь загрузкой - выгрузкой  в Open Cart.
Единственное, мне не хватает в таблицах функциональности настоящих баз данных, сказывается тяжелое реляционное детство. 
А вот как интерфейс, таблицы самое то - быстрый ввод, формулы, пользователям удобно, не надо искать кодера, что бы сделать наценки, скидки.       
Вообще у Googl' а много разных API, есть где развернуться.

З.Ы. Интересно читать, как  на searchengines  "пинают ногами"  разработчика магазина - как можно обойтись без хостинга и баз данных!! ))) 
Да, такой магазин скорее для гиков, с большим количеством недостатков, но тенденция на лицо - ИМ только на сторонних сервисах. 
Все очень быстро меняется.  

   

Змінено 9 березня 2020 користувачем Pirks

[Pirks]

Кстати IBM как и Google раздает бесплатные ресурсы, дисковое пространство для файлов и SQL хранилище. Вполне можно что-то попробовать по этой теме. 
https://cloud.ibm.com/ 

Змінено 9 березня 2020 користувачем Pirks

[heeg]

9 часов назад, Pirks сказал:

З.Ы. Интересно читать, как  на searchengines  "пинают ногами"  разработчика магазина - как можно обойтись без хостинга и баз данных!! ))) 
Да, такой магазин скорее для гиков, с большим количеством недостатков, но тенденция на лицо - ИМ только на сторонних сервисах. 
Все очень быстро меняется.  

   

Вот у разработчиков всегда так. Не смотрел, не читал, но осуждаю.  Каких недостатков? Откуда взялось "скорее всего"?   Kodak тоже сказали. "Какие цифровые фотоаппараты? Вы видели их качество?"   и были правы, но теперь их нет....  на searchengines  всегда пинают, там манера общения такая  

[Denys]

В 09.03.2020 в 08:21, Pirks сказал:

Кстати IBM как и Google раздает бесплатные ресурсы, дисковое пространство для файлов и SQL хранилище. Вполне можно что-то попробовать по этой теме. 
https://cloud.ibm.com/ 

А как только появится спрос и популярность урезать квоты на бесплатный вызов API как и Google задрать цены и считать профит? Только одного меня смущает что якобы бесплатные сервисы не дают возможности зарегистрироваться пока не дашь им данные своей кредитки.

[markimax]

3 минуты назад, Denys сказал:

А как только появится спрос и популярность урезать квоты на бесплатный вызов API как и Google задрать цены и считать профит?

Так обычно и бывает
К примеру большой облачный https://imageshack.com  так и сделал тоже
Был бесплатным облачным API для изображений, много пользователей, CMS, модулей там размещали безопасно изображения (очень удобно было замечу).
И в один прекрасный момент (в НГ 2019), бац и он уже платный.

[Pirks]

В 31.03.2020 в 17:55, Denys сказал:

А как только появится спрос и популярность урезать квоты на бесплатный вызов API как и Google задрать цены и считать профит? Только одного меня смущает что якобы бесплатные сервисы не дают возможности зарегистрироваться пока не дашь им данные своей кредитки.

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

[Pirks]

В 31.03.2020 в 18:01, markimax сказал:

Так обычно и бывает
К примеру большой облачный https://imageshack.com  так и сделал тоже
Был бесплатным облачным API для изображений, много пользователей, CMS, модулей там размещали безопасно изображения (очень удобно было замечу).
И в один прекрасный момент (в НГ 2019), бац и он уже платный.

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