Модуль магазина как отдельный сервис. Хорошая ли идея и если да, то какие есть решения?
Нам на проекте нужен интернет магазин для мерча и прочих мелочей.
Начали думать как это сделать и поняли, что все это достаточно сложно.
Надо думать о различных параметрах товаров, отчетах, складских остатков.
Возникла идея использовать отдельный сервис для интернет магазина в, котором уже все продумано и оттестировано. Взаимодействовать с ним через rest или еще какой протокол. Возможная проблема: синхронизация аккаунтов в основном приложении и в потенциальном сервисе.
Как вы считаете такой подход имеет право на существование и если да, то какие инструменты можно использовать?
UPD: У нас уже есть SPA приложение, админка к нему и laravel для rest api.
Хочется сделать так, чтобы все сложные вычисления и методы были уже реализованы где-то, а мы только для них написали UI.
Василий Банников, магазин должен быть вшит в текущее приложение. Пользователь не должен понимать, что он перешел на другой домен или открыл другой сайт. Да и мы spa используем. Все на 1 странице
Я бы мог взять opencart в качестве сервиса и взаимодействовать с ним через API, но это попахивает костылем. Может быть есть уже разработки готовые заточены под подобные проблемы
GizzaProger, тут такое дело, что пол-магазина - это витрина, корзина и оплата, которые должны быть у клиента и по API их сделать все равно не получится.
Вы, видимо, хотите shop backend as a service? Пульнул метод "Обновить остатки" и там само все как-то обновилось, а вы по другой апишке получаете актуальное состояние склада? Или передал заказ по адресу /orders/create и потом знай только статусы обновляй по тому же api через свой gui?
Просто делали нечто подобное для внутренних нужд в свое время, т.к. готовых решений найти не удалось.
romaro, Если я вас правильно понял, то да
Хочу логику уже готовую взять и только методы дергать нужные. А как там все устроено не очень волнует, если, конечно, работает все корректно
GizzaProger, данные-то на бэке обновлять получится. Но готового вы от того магазина получите - только бэк. А отображение товаров, их покупку и прочее отслеживание заказов в личном кабинете - фронтенд - все равно придется писать самим. И тут уже вопрос, поможет вам чужое решение или на его преодоление потратится больше сил, чем на самописный бэкенд.
Adamos, UI в любом случае писать придется
Да, вопрос хороший. Но можно задать эквивалетный. Позволит ли апи потенциального сервиса сделать то, что нам нужно
А нужно нам не так много.
Почему я свой не хочу сервис писать? Я уверен, что там сложностей много возникнет + баги + тестирование. Много времени суммарно займет.
GizzaProger, сложности будут те же, что при приспосабливании к вашим нуждам сторонних решений. Не стоит рассчитывать, что там из коробки будут именно ваши хотелки.
Кстати, вам вообще - реально нужен магазин? Это работа с доставкой, платежными системами и проч. Сейчас в тренде маркетплейсы, которые с удовольствием сделают это за вас, даже с мелочевкой. Мы на Wildberries вполне успешно реализуем товары, стоимость которых сравнима со стоимостью их доставки почтой...
GizzaProger, как человек, который в еком логистике почти 10 лет, скажу, что да, сложности есть... Вам по-хорошему нужен либо бекендер с опытом в екоммерс (обычно у таких по умолчанию хороший беграунд в базах данных и навыки бизнес-аналитика), который согласует с вашим фронтом API и реализует всю логику под ваш фронтенд. Это тот путь, по которому мы в свое время пошли и он не сильно быстрый.
Второй вариант вы сами назвали. Если не найдете готового решения, то почему бы не управлять готовым сервисом вроде InSales, у которого уже есть API, в том числе для управления состоянием каталога, заказами и т.д.
GizzaProger, у вас продажи за внутреннюю валюту?
С одной стороны, это проще - не нужны платежи и фискализация.
С другой - это не тот кейс, под который обычно заточены магазины ;)
Еще не совсем понятно: как у вас на данный момент реализован учет товарных остатков вашего мерча? Видимо, никак. Тогда можно присмотреться к интеграции "МойСклад" и стороннего сервиса интернет-магазина. Это все равно будет проще и быстрее, чем писать свою платформу. Пусть даже придется с какими-то костылями мириться.
GizzaProger, реальные платежи и реальные товары - это платежные системы, фискализация и доставка российскими службами. Делать это самостоятельно - не особенно приятно, но возможно (я таки делал ;) ).
Выбор готовых решений сужается до тех, которые достаточно распространены в РФ, чтобы под них писали соответствующие плагины.
romaro, Да, действительно - никак не учиываем остатки
Сейчас нет никакой системы. Я тоже думал, что интеграция с подобными вещами будет полезна. Все таки в 21 веке живем - веке автоматизации. Когда все подсчеты хочется автоматизировать и не привлекать людей в них
GizzaProger, людей к ведению остатков все равно придется привлекать, вопрос только, насколько им будет удобно работать и насколько наглядна будет эта работа.
А вам на этом этапе нужно понимание - как этот магазин будет у вас проходить по бухгалтерии и какое взаимодействие с 1С, возможно, понадобится. Интернет-магазины часто интегрируют с 1С-Торговлей, но у вас-то это явно не профильное направление.
Adamos, Не известно. Но скажу так: услажнять тоже слишком не хочется. Все таки мы мерч продаем только для большей вовлеченности в обучение, а не специализируемся на этом
Простой
Простой
Средний
