Ищу Candidat CMS

Давай с задачей.

У меня есть бизнес, и в нем есть система управления(иначе "как жить"), так ?

Теперь мне нужен ИМ, так ?

Где-то у меня уже заведен этот товар, погонные метры, фиксированные длины итп.

Что я по-твоему должен сделать ?

По-моему я должен сгенерировать html-документ, который позволит мне продать эти "метры".

И выложить его в ИМ.

А ИМ должен вызвать мою основную систему управления и передать ей "товар ХХ куплен, количество ХХХ, доставить клиенту ХХХХ".

Зачем мне в ИМ какая-то БД ?

Чё в ней хранить ?

---------- Добавлено 10.01.2020 в 16:02 ----------

Что значит "может меняться" ? Каждую секунду ?

Тут нужен шаблонизатор. Зачем тут база ?

PS. Не хочешь шаблонизатор - заведи js :) вставляй им куда надо свои "офисы" и если понадобится в нём меняй. База зачем тут ?

То, что нужно для фронтенда именно интернет-магазина и чего нет в системе товарного учета, как не ее сущностей

- категории

- фильтры

всякая прочая динамика для визуализации (которая таки нужна там, где нужна). Так что для RDMS в ИМах место все же есть

Категории получаются "сразу", в том смысле, что выгружаются отдельно из системы управления "готовыми".

Фильтры и поиск - да, проблема. Я об этом пишу в каждом первом сообщении.

Если много и разного - придется городить что-то... возможно БД.

Если мало... то я один раз сгружаю на сторону клиента 100кб данных и уже на его стороне всё это обрабатывается.

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

При этом, к примеру, поиск по названию и подсказки для него происходит абсолютно мгновенно.

Да и фильтрация тоже. Приезжает только графика "не сразу"

Что бы сгрузить что-то нужно это что-то получить) Весь товар хранился( не к ночи сказано) в 1С )))

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

А если руками добавить товар в админке с теми же вариациями - тож в файл его?

Понятно, что можно написать админку и для таких извращений, но будет ли оно того стоить?

Ух, вспомнил и страшно стало))) слава богу отошел от этого

Да хоть сотни.

Из 1С выгружается готовый какой-нибудь "json" или то, что надо, он упаковывается и посылается один раз пользователю.

И потом с клиентской стороны это всё курочится.

Весь вопрос только в размере файла и объеме обработки на клиенте. Если допустим - делаем, нет, изобретаем что-то еще.

Для сотен и тысяч товаров это будет работать, для сотен тысяч наверное нет.

О какой админке вы говорите :) ?

Нет никакой админки, зачем она ИМу вообще :) ?

Хотите продавать товар ? Заводите в 1С, после чего он синхронизируется с ИМ и товар появляется.

Вы ведь все равно не сможете продать то, чего в 1С нету... никак.

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

Еще раз подчеркиваю: всё это только в случае, если ассортимент не слишком большой и поисковая база может быть доставлена клиенту. Таких случаев 99.99% от общего числа ИМ.

Если "слишком", то увы, вероятно придется из 1С заполнять какую-нибудь базу и в ней искать уже потом.

Будет это SQL или какие-нибудь "эластики" - вопрос 10й.

Однако база эта скорее всего будет содержать только одну таблицу, собственно для поиска/фильтрации по ней.

Возможно весьма избыточную таблицу.

А как еще-то :) ?

_SP_, Для ИМ задач на самом деле там много:

1. В системе хранения скорее всего учет не тот, что есть на сайте (Например на сайте продаются компьютеры, а в системе учета все по комплектующим, то есть в момент синхронизации заказов, компьютеры надо разбить на комплектующие)

2. Список пользователей и работа с ними, где покупателей хранить?

3. Любой внешний обмен на запросе пользователя это смерть ИМ, по этому все обмены вынесены с запросов юзеров, например надо быть дебилом чтобы отправлять смс юзеру, ведь гетвей может подвиснуть на 30 секунд и юзер будет ждать загрузки страницы 30 секунд.

4. Никакая система учета не выдержит той нагрузки что выдерживают ИМ.

5. Надо вести учет, статистику и аналитику.

6. Надо обогащать данные карточек товаров.

7.Нужно строить связи для доп и крос продаж.

8. В конце концов транзакции в ИМ нужны не только для остатка в учете но и для резервации товара, консистентных изменений в учетных данных юзеров и так далее.

Я не говорю что какой то классический простой ИМ нельзя построить чисто на статике - можно. Но это сильно сложнее с хотелками в екоммерсе. А вот построить простой сайт на статике, фф цмс и прочих простых инструментов на мой взгял решение идеальное. Практически все что делается на ВП например, можно запилить в виде статики, с шаблонизаторами на JS и компиляцией ноды, чтоб на выходе был чистенький код, залить его на cdn и получать максимальные скорости, которые невозможно положить никаким ддосом и прочими активностями.

Поднимите мне веки! И покажите того, у кого в 1С заведена таксономия вся кучерявая, даже не на очень комплексный товар... недавно вот делал фильтры ювелирщикам на "вроде бы простой" товар - кольца. И там было - много. А еще не просто таксономии, а пересечения и объединения... не, только по месту (то бишь - на морде сайта), в остальных местах народ оперирует артикулом и ему хватает

Зачем её в 1С заводить? Лучше одной единственной ограничить, далее не сложно при экспорте раскидать по ключам, категориям, алиасам, пересечениям и т.п.

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

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

прилично, но не критично, сейчас бутстрапы, семантики и прочие css фреймворки весят в стандартной комплектации больше

Для своих целей cms на файлах вместо базы данных вполне подходят.

Они не универсальное решение, но достаточно удобное. Эти системы отлично подходят для сателлитов (тут еще помнят что это и зачем, на других форумах уже и не все знают, пришли с smm), дорвеев (например, пандора), лендингов.

У меня свое решение, все метатеги, seo, указания категорий - это синтаксис (twig, django) которые расширяют базовый шаблон при необходимости. Из готовых пока за grav и get simple

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

Вывод - есть навыки программирования и(или) понимание для чего это нужно, то использовать однозначно.

Уровень - собираю из плагинов крутые сайты, то использовать не рекомендуется, потребуется seo подправить, будет множество возмущений, как так оно не работает, когда там одним плагином всё делается, тут 10 штук и не то что нужно, хотя достаточно было 3 строки кода добавить.

Ни вывод ни уровень непонятен. Понятно, что всему свое место, но всегда хорошо иметь универсальный инструмент для основы. Лично мне проще даже лэндинг на джанге запилить, потому что потом расширять проще. Очень редко хотелки останавливаются у заказчика. Не вижу ничего плохого в использовании БД практически всегда.

Вот у нас последние 2 дня эластик убивает сервис напрочь - админы ищут ошибки и пока безрезультатно.

У вас джанга без базы?

Затем, что далеко не весь "мусор" (который для ИМ - вполне рабочие и нужные, а порой - необходимые данные) нужен в 1С..

Более того, отдельная информация в 1С категорически не нужна..

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

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

* при среднем названии в 100 символов (UTF), описании в 2к символов (тоже UTF, но без всяких смайликов), всякой служебной инфы ещё (цены, наличие-остатки, минимальный заказ, возможность доставки туда-сюда, габариты, вес ...

Харакеристики-вариации с ценами пока опустим, но в уме иметь в виду..) (чтоб считать "круглее" было - берём грубо условных 4000 байт на товар)... Т..е 1к товаров будет занимать примерно 3,8 Мб (без сжатия). 10к товаров, соответственно - 38Мб, 100к - 380Мб...

Пусть мы на лету эффективно сожмём это раз в 10 до 38 Мб..

а) качаться оно будет ощутимо даже при хорошем интернете...

б) на клиенте его нужно распаковать.. и работать с ним как-то..

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

А зачем изобретать "что-то ещё", если можно вполне нормально делать?..

Тем более, что в современных реалиях увеличение ассортимента на тысячи - десятки тысяч товаров - вполне обычный итог договорённостей с новым поставщиком.

На таких объёмах товаров (условные 100к) на "нормальном" хостинге с поиском справится и MySQL без эластиков-сфинксов.. Придумывать "что-то ещё" без значительного изменения архитектуры при увеличении количества товаров первое время можно за счёт переходов на бОльший тариф, выделения дополнительных к тарифу ресурсов, переезда на более мощный VPS-дедик, добавление "кубиков" масштабируемому VPS-у, выноса базы на отдельный ресурс,

Естественно, в какой-то момент проще использовать специализированные решения.. Но, всё же, организация поиска по ИМ на клиенте - это, имхо, не очень подходящее решение для ИМ..