Комментарии

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

В 2022 году мы решили изменить подход и перейти на решение «Сотбит» от «Битрикса». Мы продолжали работать над проектом, но столкнулись с отсутствием технической поддержки после продажи. Мы поняли, что проблема не только в сложности системы, но и в том, что наш маркетплейс не выдерживает нагрузок. Даже с небольшим количеством товаров и трафика система работала нестабильно.

Оптимизация базы данных и серверов не принесла результатов. Мы обратились к специалистам, которые подтвердили, что проблема в самой платформе «Битрикс».

В 2023 году мы перешли на CS Cart. Сначала всё шло хорошо, мы даже приобрели версию «Энтерпрайз». Однако через полгода работы с техподдержкой и разработчиками мы столкнулись с серьёзными проблемами. Разработчики сообщили, что в движке много проблемного кода, который нужно переписать для работы с 100 000 товаров. Ошибки и сбои в системе стали ежедневным явлением, а импорты, экспорты и доставки не работали должным образом.

Измотанными мы решили обратиться к другому решению. Сейчас мы работаем на ДСТ Маркетплейс. Здесь нас радует бесплатная техническая поддержка, в отличие от CS Cart, где поддержка платная и не всегда доступна. Мы заплатили за CS Cart 1,2 миллиона рублей, но получили движок с множеством ошибок. За ДСТ Маркетплейс мы заплатили 650 тысяч рублей, и он работает без проблем.

Запуская MVP, важно тщательно выбирать не только платформу для работы, но и техническую поддержку. Даже если у вас есть свои разработчики, поддержка всё равно необходима.

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

В 2022 году мы решили изменить подход и перейти на решение «Сотбит» от «Битрикса». Мы продолжали работать над проектом, но столкнулись с отсутствием технической поддержки после продажи. Мы поняли, что проблема не только в сложности системы, но и в том, что наш маркетплейс не выдерживает нагрузок. Даже с небольшим количеством товаров и трафика система работала нестабильно.

Оптимизация базы данных и серверов не принесла результатов. Мы обратились к специалистам, которые подтвердили, что проблема в самой платформе «Битрикс».

В 2023 году мы перешли на CS Cart. Сначала всё шло хорошо, мы даже приобрели версию «Энтерпрайз». Однако через полгода работы с техподдержкой и разработчиками мы столкнулись с серьёзными проблемами. Разработчики сообщили, что в движке много проблемного кода, который нужно переписать для работы с 100 000 товаров. Ошибки и сбои в системе стали ежедневным явлением, а импорты, экспорты и доставки не работали должным образом.

Измотанными мы решили обратиться к другому решению. Сейчас мы работаем на ДСТ Маркетплейс. Здесь нас радует бесплатная техническая поддержка, в отличие от CS Cart, где поддержка платная и не всегда доступна. Мы заплатили за CS Cart 1,2 миллиона рублей, но получили движок с множеством ошибок. За ДСТ Маркетплейс мы заплатили 650 тысяч рублей, и он работает без проблем.

Запуская MVP, важно тщательно выбирать не только платформу для работы, но и техническую поддержку. Даже если у вас есть свои разработчики, поддержка всё равно необходима.

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный урок, который я извлёк из этого опыта: даже для MVP лучше сразу заложить достаточный бюджет и тщательно выбрать платформу. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё необходимое.

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный урок, который я извлёк из этого опыта: даже для MVP лучше сразу заложить достаточный бюджет и тщательно выбрать платформу. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё необходимое.

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

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

Я не уделил достаточно времени изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный урок, который я извлёк из этого опыта: даже для MVP лучше сразу заложить достаточный бюджет и тщательно выбрать платформу. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё необходимое.

Основная проблема не в этом а в том что все это прибито намертво гвоздями в ядре.

В тем проблема вынести это в отдельный service provider и дать выбор пользователю самому решить где и что в каком виде хранить?

В итоге приходиться делать патч на ядро а это боль и при обновлении все это слетит.

И ещё у Laravel странное поведение кеша. А ещё постоянные с архитектурой. Например, то мы модели в одном месте храним, то в другом, то снова в первом.

вот поддержал бы, последний год проект вели на Yii2, всё отлично было
в этом решили сделать его форк на Laravel, сделав упор на оптимизацию, переписав логику, упростив процессы и после Yii2 Лара просто вызывает удивление. Yii2 из коробки убирает возню с маршрутами, с генерацией CRUD, простое введение ролей в проект за счёт RBAС, валидация простая и понятная, шаблоны в плане синтаксиса как-то поаккуратнее шаблонов блейда выглядят. В Ларе мы успели и с путями покуролесить, и с валидацией поморочились, и CRUD-генератор, который варит контроллеры/модели/формы, тоже искали. В Ларе строка текста, которая имеет переводы, выглядит как __('admin.Enter name'), к нам подходил джун, спрашивал, что это за «магические методы у нас в формах, я не знаю, как такое гуглить»))
Да, мы потом со всем разобрались и настроили, но Yii2 из коробки в плане документации и удобства выглядит как зрелый, цельный фреймворк, а Лара как хайп-фреймворк, который дёргал с миру по нитке + такое ощущение, что эти люди страшно скучали по разработке на javasript)
п.с: хотя у этих фреймворков, скорее, разные назначения и возможности, но вот как раз в плане удобства Yii2 как раз, имхо, максимально удобен, а на основные вещи есть даже актуальная документация на русском

А мне после Yii2 Laravel кажется жутко неудобным. Особенно после AR и Yii2-debug. Но это всё дело вкуса.
>Laravel хорош для новичка
О да, то, что новички вытворяют на Laravel, такого ужаса на Yii мне не встречалось. Кстати, документация у Yii2, как по мне, более удобная и информативная.

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

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

Laravel хорош для новичка — все из коробки, просто развернуть, просто работать — но как только появляется необходимость что-то поменять в ядре — жизнь боль, Job's если поменять параметры конструктора — тоже валяться на раз два. При работе с миграциями — необходимо быть предельно осторожным.

Symfony — монстр с решениями на все случаи жизни, но на его изучение также придется потратить пару жизней.

Zend — раньше жил только за счет его форса ZendFoundation и был жутко неудобной страшной штукой. Сейчас (Laminas) даже не смотрел.

Yii — Собран на коленке для создания проектов на коленке, после laravel покажется жутко не удобным.

Phalcon — был актуален на php5.6 так как работал намного быстрее всего что было тогда — за счет того что ядро скомпилировано как плагин php. При php >= 7.0 уже почти не имеет смысла так как из самого php выжали почти все возможное и теперь дожимают остальное.

Все остальное — уже жуткий legacy — проще с нуля собрать свой фреймворк с помощью php-di

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

Недавно я запустил MVP маркетплейса. В отличие от многих, я выбрал WordPress с WooCommerce и добавил плагины для поддержки мультивендорности. Это оказалось бюджетным решением, но потребовало много времени на интеграцию. Позже выяснилось, что WooCommerce — это не самый удачный выбор. В личном кабинете поставщика нет важных функций: нет информации о комиссиях, уведомлений, фильтров в каталоге. Система доставки тоже статичная, а не через API. Я не уделил достаточно внимания изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный вывод: даже для MVP лучше сразу заложить достаточную сумму и тщательно выбрать систему. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё, что нужно.

Недавно я запустил MVP маркетплейса. В отличие от многих, я выбрал WordPress с WooCommerce и добавил плагины для поддержки мультивендорности. Это оказалось бюджетным решением, но потребовало много времени на интеграцию. Позже выяснилось, что WooCommerce — это не самый удачный выбор. В личном кабинете поставщика нет важных функций: нет информации о комиссиях, уведомлений, фильтров в каталоге. Система доставки тоже статичная, а не через API. Я не уделил достаточно внимания изучению всех возможностей платформы, и в итоге 160 тысяч рублей были потрачены впустую.

Главный вывод: даже для MVP лучше сразу заложить достаточную сумму и тщательно выбрать систему. Сейчас я работаю с ДСТ Платформ. Это дороже, но первые продажи начались уже через месяц после запуска. Такой подход действительно работает, и в движке есть всё, что нужно.

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

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

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

В целом, для обеспечения эффективности могут быть выделены три основные составляющие:

— хранение данных должно происходить распределённо, то есть внутри сети, которая состоит из нескольких ЭВМ, несмотря на то, что сами файлы могут быть достаточно большими;

— необходимо создать такую схему хранения данных, которая обеспечит существенные преимущества по сравнению с традиционными реляционными базами данных, несмотря на то, что сами данные являются разреженными;

— схема обработки данных должна строиться так, чтобы они обрабатывались непосредственно на той машине, где и находятся. Это позволит избежать передачи огромного массива по сети и в конечном счёте поднимет производительность.

Как правило, реляционные базы выбирают для работы со сложными запросами и обработки рутинных задач. И здесь следует учесть вот что: SQL-базы масштабируются по вертикали, то есть с помощью увеличения нагрузки на отдельный конкретный сервер. В свою очередь, NoSQL-базы хорошо масштабируются по горизонтали за счёт увеличения количества серверов, что является весьма удобным при работе с большими объёмами данных, так называемыми Big Data.

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

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

Среди некоторых из популярных нереляционных баз можно перечислить: MongoDB, Apache Cassandra, Couchbase.

давайте оставим авиакомпании, там все понятно, но по 3му пункту уточню: я нигде не пытался «опровергнуть CAP» — наоборот, в рамках имеющихся ограничений физического мира инженеры придумали как их можно «почти обойти» — и для подавляющего большинства бизнес кейсов можно сказать что «Spanner поборол CAP теорему» — и это будет почти правда с практической точки зрения и оговоркой что относительно небольшая часть данных может быть недоступна относительно короткие промежутки времени.

Хм. Очень интересный комментарий. Попробую по пунктам.
1. Здесь на самом деле парадоксальная ситуация. Теоретически они должны выбирать CP, чтобы гарантировать точность данных и избежать продажи одного и того же места нескольким пассажирам. Практически они выбирают AP, чтобы обеспечить высокую доступность и работоспособность в условиях сложных взаимодействий между глобальными и локальными системами. Это как бы не противоречит CAP. Скорее показывает практическое применение.

2. Да, все верно. Многие компании продают билеты сверх лимита на досадку, основываясь на статистике. Здесь двоякая ситуация. С одной стороны бизнес-решение, а с другой можно рассматривать, то фактически является способом адаптации к невозможности обеспечить строгую согласованность в распределённой системе. И демонстрирует, как бизнес-процессы могут дополнять технические решения, чтобы минимизировать последствия ограничений, описанных в теореме CAP.

3. Агась! Но это скорее не опровержение теоремы, а отличная демонстрация, как технологии развиваются. Spanner — отличный пример минимизации ограничений, описанных в CAP. При этом CAP не утверждает, что невозможно достичь всех трех свойств вообще. Теорема говорит, что невозможно гарантировать их одновременно в любых условиях. Spanner достигает всех трех свойств в подавляющем большинстве случаев, но допускает временные потери Availability в экстремальных условиях.

Во первых, де факто многие системы продажи авиабилетов являются распределенными (т.е. дают гарантии eventual consitency), что связано со сложными взаимодейтсвиями разных систем(глобальных интеграторов, локальных систем авиакомпаний, турагенств и тд).

Во вторых, некоторые авиакомпании(особенно в штатах) осознанно делают overbooking(продажи нескольких билетов на одно место), потому что статистически какой то % народа не является на посадку и тогда все хорошо. Если на посадку приходят все, то предлагают деньги желающим за то чтобы «полететь завтра», а если все хотят «полететь сегодня» — рандомно выбирают неудачников и советуют почитать что написано мелким шрифтом в соглашении по покупке билета.

Ну и третьих, оно же главное: принцип CAP был сформулирован 25 лет назад и с той поры лучшие инженеры потратили много сотен тысяч часов для того чтобы этот принцип обойти — и это получилось. Это Cloud Spanner от гугла. Если коротко, то там придумали как выкрутиться и нашли компромис который (почти)гарантирует все 3 свойства CAP в подавляющем числе случаев использования, ослабляю гарантии по Availability с существенными оговорками.