Как написать собственную платформу для e-commerce?

Question

[Jeff_Parker]

Добрый день
Все растет, моя компания в сфере e-commerce, в том числе. Сегодня мы используем кустарные скрипты, приложения на локальных машинах, а в качестве базы данных вообще - гугл таблицы. Раньше этого было достаточно, но с расширением количества товаров, ростом кол-ва ячеек в таблицах становится ясно, что нужно с этим что-то делать...
Будучи единственным программистом в компании на меня взвалили тяжелую ношу - провести ресерч технологий, которые могли бы помочь создать человеческую инфраструктуру. Незавидная судьба, учитывая что сам я посредственный node js джун
Из функционала - необходимо взаимодействие с API сторонних сервисов, внесение данных, создание статистики и автоматизация рутинных процессов. Что можете посоветовать?

Comments

[Andrei SunnyPh]

Ozon.ru для E-commerce внедряла примерно такую архитектуру:
1. Часть фронтенда на Vue.js
2. Часть Фронтенда, используя Razor из ASP.NET Core
3. Интегральная платформа для бекенда ASP.NET Core
4. Микросервисы на Go
5. Базы данных разные под различные сервисы, и SQL и no SQL...
Ну это очень примерно..., но может служить неким ориентиром, в какую сторону ветер дует....))

Answer 1

[Adamos]

Используйте вместо гугл таблиц базу данных. Раз знаете ноду - видимо, сможете поднять на ней сервис, работающий с БД по запросам извне - это и будет API. Потом напишите веб-странички, которые в том же JS обращаются к API и рисуют на фронте данные в табличках и интерфейсы для изменения... а там видно будет.

Comments

[Jeff_Parker]

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

[Adamos]

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

[Adamos]

Jeff_Parker, вам сейчас важно не растекаться по древу - как сделать оптимально и навеки. Хрен вы сделаете так сразу, без опыта. Вам нужно не бояться сесть и начать писать, как получается.
Но стараться не смешивать - то есть делать API настолько абстрактным, насколько это вообще возможно, чтобы работу БД за ним можно было однажды взять и переписать полностью, не меняя ничего в API.
И когда что-то вас перестанет устраивать и появится понимание, как это можно сделать правильнее - выкинуть старье и все переписать. Уже понимая, что, зачем и почему именно так делается в вашей системе.

Answer 2

[ThunderCat]

Тут уже понаписали... Но я докину...
что собственно нужно в первую очередь (читать и обязательно знать), и что можно допилить потом:

1) Нормальная структура бд. 3 нормальная форма, нормализация, денормализация, отношения один-к-одномму, один-ко-многим, многие-ко-многим. В плане SQL - обязательно работу с джоин, груп бай, агрегационные фунции - сум, коунт... В дальнейшем понадобится почитать про индексы, иначе будет тормозное г-но.

2) Структура кода. Проще всего взять готовый фреймворк типа Express под ноду, но тут еще понадобится читать туториалы и все вот это, зато костылей будет в разы меньше, и оптимизировать код в тысячи раз проще.

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

В общем как то так...

Comments

[Adamos]

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

[ThunderCat]

Adamos, Ясен пень, крутить надо под себя. как по визуалу/фишкам, так и по собственным силам.

Answer 3

[Михаил]

Какой вопрос, такой ответ: "Взять и написать".

Для этого можно использовать любые технологии, которые позволяют разрабатывать для Web. Все вами перечисленное сделать можно без особых проблем на:
PHP (Symfony/Doctrine, Laravel и т.п.)
Java/Kotlin (Spring)
Node.js
Python (Django)
и прочие.

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

Comments

[Adamos]

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

[Jeff_Parker]

Как построить архитектуру? С чего начать? Какие мануалы стоит изучить?
Потребности в частности описаны в вопросе. Предполагается использование внутри компании сотрудниками. Необходимо создать платформу, совмещающий большинство процессов в компании
С выбором технологий все гораздо проще - уже положил глаз на mySQL и ноду (просто потому что знаю только её)

[Михаил]

Adamos, при наличии архитектуры, постановки задачи и некоторого опыта - да может.

[Adamos]

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

[Михаил]

Jeff_Parker, с архитектурой вопрос весьма непростой. И тут, как водится, две крайности:
1. "Как бог на душу положит". Ну то есть "что сейчас надо сделать - то и пишем. Через какое-то время (большое или малое - непринципиально) сопровождать это станет невозможно и придется "выкинуть и переписать с нуля". В принципе вполне пригодный подход, если речь идет о прототипе. Прототип - это некий демонстратор принципа, технологии, который всегда идет в мусорку после того как выполнил свою задачу.
2. Читая, хорошая, правильная архитектура. Тут я отправлю читать Р. Мартина - "Чистый код", "Чистая архитектура" и "Идеальный программист". Главный принцип хорошей архитектуры - это разделение на модули, каждый из которых выполняет какую-то свою задачу + изоляция этих модулей (взаимодействовать одни должны только через определенной API) + иерархия зависимостей (модули, содержащие абстрактную логику не должны зависеть от модулей содержащих детали реализации - "детали зависят от абстракций, но не абстракции от деталей") + покрытие тестами (в идеале TDD).

Главное преимущество хорошей архитектуры - система может развиваться долго и успешно.
Главный недостаток (с точки зрения бизнеса) - она небесплатна, это требует ресурсов на разработку и поддержание.
Истина, как всегда зависит от конкретных условий в которых вы работаете :)

[Adamos]

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

[Jeff_Parker]

Adamos, хаха, эту самую книгу мне подарила компания на день рождения)

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

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

[Adamos]

Jeff_Parker, да нет, читать эти книги - полезно. Но - не вместо.

[Михаил]

Jeff_Parker, на самом деле, когда читаешь эти книги имея опыт говнокодинга, то многое встает на свои места со звуком "ах тыж, блин! Где ты раньше был, когда я по этим граблям танцевал?"
Когда читаешь эти книги не имея такого опыта - часто возникает недоумение "ну зачем все так сложно? Я же могу сделать проще, быстрее и с таким же результатом". Но во втором случае тут важно понимать - "дядюшка Боб" очень опытный программист-практик (и остальные авторы популярных книг - тоже). И за его советами обязательно что-то стоит. И можно попробовать делать так как он рекомендует, просто в режиме "так надо". И по мере набора опыта тоже начнет появляться понимание - вот это решение мне облегчило жизнь здесь. Вот это здесь. Это может быть облегчит в будущем. А вот это я пока не понимаю... И постепенно придет опыт, начнется формирование вашего личного инструментария хороших практик. Какие-то вещи, предлагаемые авторами книг вы возьмете без изменений, какие-то подстроите под себя, под свой стиль, от каких-то откажетесь полностью. И это нормальный процесс.

Answer 4

[Alexej Simakov]

Ищите готовые решения в open source сегменте. Что-то типа Magento.
Вы правильно делаете, что не переоцениваете свои силы. Написать работающую безопасную систему вам никаких ресурсов не хватит и опыта, ведь придется параллельно поддерживать старое решение.
У готовых решений есть пользовательская база, они проверены временем, многие типовые задачи уже были кем-то решены. А магента сейчас вообще под крыло адобе перешла, и они например вкладываются в образовательные ресурсы по платформе. Я вижу одни преимущества. Ну есть еще OpenCart, она вроде более легковесная, их часто сравнивают.
А потом просто ищите как залить туда свои данные, уж импорт данных есть в таких системах, через XLS там, или CSV.

Comments

[Jeff_Parker]

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

[Alexej Simakov]

Jeff_Parker, тогда вам получается нужна т.н. Inventory Management System либо Warehouse Management System. И уже к ней прикручивать коммуникацию с маркетплейсами.

Answer 5

[Константин Нагибович]

взаимодействие с API сторонних сервисов, внесение данных, создание статистики и автоматизация рутинных процессов. Что можете посоветовать?

Могу посоветовать 1С в вашем случае. Но вы уже выбрали тот стек, которым владеете.