Мысли и выводы, опубликованные в данной статье, сформировались на основе опыта моей компании, которая не первый год занимается разработкой онлайн маркетплейсов разного типа. Мы имеем достаточно большое количество проектов, которые создавались с использованием Ruby on Rails. Сейчас же я хочу рассказать, почему мы отдали наше предпочтение именно этому фреймворку и ни разу об этом не пожалели.
Коротко о том, что такое "маркетплейс" и его специфике
Макретплейс – это электронная торговая площадка, оформленная в виде веб- или мобильного приложения, где покупатели и продавцы могут общаться и заключать сделки. Это своего рода механизм, который помогает установить связь между провайдерами. От обычного интернет-магазина маркетплейс отличается тем, что в нем представлено не один (обычно, он же и владелец), а много различных брендов поставщиков услуг.
Для общего понимания, вот основные отличия маркетплейса от интернет-магазина:
- В маркетплейсе не один, а множество различных брендов
- Самому продавцу нет необходимости заботиться о функционале магазина. Его задача – предоставить информацию о своих товарах
- Обычно, маркетплейс со временем получает признание и статус, так что продавцу нет необходимости дополнительно раскручивать свою точку продаж. Покупатель с большой вероятностью найдет бренд в маркетплейсе
- В отличие от интернет-магазина, которому еще нужно получить доверие покупателя, маркетплейсу покупатель уже доверяет, и у него возникает меньше сомнений касательно какого-либо бренда, представленного там
И это лишь основные моменты. Таким образом, покупатель получает удобную площадку, где есть буквально всё; продавец получает больше покупателей без лишних затрат на промо (чем не дополнительный канал продаж?); владелец маркетплейса получает доход без лишних "телодвижений" (ведь, все, что ему необходимо делать – не изготовлять товары и доставлять их, а создать и поддерживать маркетплейс).
В качестве примера маркетплейса можно рассмотреть Amazon, Airbnb, Uber, Spotify или OLX. Эти гиганты давно себя зарекомндовали на рынке. Кроме того, не следует забывать и про App Store с Google Play, ведь это тоже маркетплейсы. И мы практически каждый день ими пользуемся.
Важный для понимания темы нюанс – маркетплейсы разделяются на различные типы на основе принципов взаимодействия покупателей и продавцов. Всего их насчитывается 8 на сегодняшний день:
B2B (англ. "business to business"),
mCommerce (сокращение от "мобильная коммерция"),
Crowdfunding (от англ. "crowdfund" – "финансирование посредством сбора денег у сообщества"),
C2C (англ. "customer to customer" – "потребитель для потребителя"),
eCommerce (сокращение от "электронная коммерция"),
B2C (англ. "business to customer"),
peer-to-peer (от англ. "равные для равных")
auction platforms (от англ. "аукцион")
Но давайте ближе к теме. Прежде, чем начать восхваление Ruby on Rails (далее в статье RoR), в контексте разработки маркетплейсов, наверное, нужно также упомянуть и альтернативы, которые присутствуют на рынке. Дабы материал не показался предвзятым.
Вы должны понимать, что в свое время мы использовали и другие технологии создания маркетплейсов помимо RoR. Поэтому нам есть с чем сравнить.
Способы создания онлайн маркетплейсов
Это самое интересное. На самом деле, способов предостаточно. Порой более чем, поскольку каждая компания, предоставляющая платформу для разработки, твердит, что только эта платформа идеально подходит для вашего маркетплейса. Остальные "непременно будут плохо работать или иметь ограниченный функционал". Однознаности нет, и каждый вибирает сам.
Функционал, кстати, вполне отдельная тема. Ведь чтобы пользователь остался с маркетплейсом, нужно продумать кучу вещей, начиная от удобной авторизации, заканчивая интеграцией с платежной системой. О функционале можно долго говорить, но вот основные моменты:
- Дизайн интерфейса
- База данных для веб приложения и язык программирования
- Авторизация и безопасность
- Функционал для инфтерфейсов покупателя и продавца
- Функционал товарных списков
- Процесс заказа
- Функционал совершения оплаты и получения средств на счет
- Возможность для состевления рейтингов и написания отзывов
- Напоминания и уведомления
- Организация возможности поиска
И это далеко не все...
Но вернемся к способам разработки. Поскольку их достаточно много, то удобнее всего будет отсортировать их на 3 категории:
Покупка готового решения
Здесь я имею в виду покупку решения от Shopify, Magento или Woocommerce (на самом деле, примеров больше). Просто, быстро, удобно. Но есть и минусы. Основным минусом такого способа является невозможность кастомизировать ваш маркетплейс, настроить так, как вам удобно. Он будет шаблонным, и внести в него требующиеся вам изменения будет если не невозможно, то очень дорого в итоге. И если таких потребностей у вас нет, то решение идеально подойдет.
Использование открытой платформы
Такая открытая платформа, как, например, Sharetribe, WordPress или Spree – это что-то среднее между кастомной разработкой и готовым решением. С одной стороны, здесь вы получите большую свободу для настроек и изменений. По сути, разработкой будет заниматься ваша команда. Но в то же время, создать здесь нечто более, что выходит за рамки возможностей платформы, не получится.
- Разработка с нуля
Наконец, вариант, о котором я хотела вам рассказать. Разработка с нуля предусмотрена для уникальных маркетплейсов, где функционал, технологии и прочие детали мы можем выбирать, изменять и дополнять на свое усмотрение. Таким образом мы получим свое собственное приложение, созданное с учетом всех наших потребностей и планов. Никаких ограничений.
По стоимости и времени на разработку этот вариант может показаться самым затратным. Но не стоит забывать, что в итоге мы получим продукт, не требующий дополнительных изменений (в идеале, конечно).
Для разработки с нуля используются различные фреймфорки (англ. "web application framework").
Разработка онлайн маркетплейса с Ruby on Rails
Несмотря на то, что для каждой платформы находится много любителей и противников (маркетплейсы также часто создаются на платформах Laravel, Django, Meteor), мы предпочитаем именно Ruby on Rails.
И вот почему:
Во-первых, это простота разработки. Для RoR существует огромное множество библиотек, где есть все, о чем можно только мечтать. Даже если вопрос или проблема еще не появились, для них уже есть решение.
Это очень удобно, ведь ничего не нужно изобретать.
Эта же простота разработки приводит к следующему преимуществу – значительному сокращению времени на разработку. Что может быть лучше, если проект можно запустить в два раза быстрее, чем планировалось ранее? К тому же, именно из-за простоты, команда разработчиков сравнительно невелика. А это – очевидная экономия.
RoR рассчитан на сайты с большим количеством информации. Другими словами, если нужно предусмотреть наполнение сайта контентом, то нет ничего лучше, чем Ruby on Rails. Это очень важно для CRM и CMS систем.
- У RoR одно из самых больших и активных сообществ разработчиков, которые всегда готовы помочь или прийти на выручку. Это очень важно, когда долго ломаешь голову в поисках неочевидного ответа. Вероятность, что другой разработчик уже ее поломал и нашел ответ, очень велика.
Сообщество разработчиков может прийти на выручку и тогда, когда необходимо заменить или нанять еще одного разработчика в команду. С поиском кандидата не будет проблем.
Существует огромное количество маркетплейсов, возданных на Ruby on Rails. Тот же Shopify (о котором шла речь ранее) или всемирно известный Couchserfing.
Можно долго говорить о том, как хорошо и легко работать на RoR. Однако, основная цель моей статьи – рассказать, что этот фреймворк прекрасно подходит для создания онлайн маркетплейсов. Надеюсь, что мне это удалось, и информация как про маркетплейсы, так и про Ruby on Rails была для вас полезной.
Комментарии (14)
zharikovpro
07.08.2017 22:18+2> Однако, основная цель моей статьи – рассказать, что этот фреймворк прекрасно подходит для создания онлайн маркетплейсов
По-моему вы просто как раз рассказали «Можно долго говорить о том, как хорошо и легко работать на RoR.» Где специфика именно про маркетплейсы? Можно заменить это на «приложения» и смысл статьи не изменится.
IrynaKorkishko Автор
08.08.2017 10:29Моя статья рассказывает про маркетплейсы: их виды, специфику, функционал. Поэтому логично, что я рассматриваю использование рельсов конкретно под создание маркетплейсов. Это да.
Если же говорить про различные веб и мобильные приложения, то руби он рейлс тоже подходит и для большинства из них. Но всегда нужно исходить из специфики проекта. Ограничивать себя исключительно рельсами, разумеется, глупо.
Как я и упоминала в начале, статья базируется на опыте нашей компании, которая занимается разработкой маркетплейсов (не только, конечно, но в значительной мере). В контексте этого я и рассказываю, почему мы используем именно RoR для создания маркетплейсов. Почему это удобно, быстро и относительно просто.
G-M-A-X
08.08.2017 10:12-1Ниачем :)
Для разработки с нуля используются различные фреймфорки
Если квалификации хватает, то можно и на голом языке (PHP). В нем есть все нужное. :)IrynaKorkishko Автор
08.08.2017 10:48Можно хоть и на РНР. Вопрос в том, стоит ли овчинка выделки. Но мы не про язык, а про фреймфорк. С рельсами уже имеется проторенный путь, стоит только конфигурировать необходимые части — и все готово.
Изощряться, впрочем, можно по-разному. Писать на РНР может и студент, конечно. Дело не в том.
Возвращаясь к фреймворку, с рельсами программисту будет значительно проще, поскольку там уже достаточно готовых для использования вещей. К тому же предпочтения языка программирования — всего лишь дело вкуса. Например, многие предпочитают руби только потому, что его синтаксис понятен без лишних обяснений. Что делает работу легче и приятнее.
Так что комментарий, простите, «ниачем».
xenm
08.08.2017 10:52Из статьи совершенно не понятно, почему RoR прекрасно подходит для создания онлайн маркетплейсов.
IrynaKorkishko Автор
08.08.2017 11:10Здравствуйте!
RoR прекрасно подходит для создания маркетплейсов, в первую очередь, потому, что с ним создать маркеплейс можно очень быстро. Заказчики нашей компании обычно нуждаются в готовом продукте или работающем прототипе «вчера». Поэтому времени на то, чтобы искать новые пути создания, нет. Использовать готовые решения тоже не вариант, поскольку необходимой кастомной конфигурации из них не слепишь. И в результате все обойдется дороже, дольше и не так, как того хотел заказчик.
Поэтому остается вариант с разработкой с нуля, чтобы все сразу было создано так, как нужно. И здесь есть проторенные дорожки с готовыми решениями руби он рейлс. Их достаточно просто конфигурировать, доработать, внести изменения — и вуаля.
Конечно, скажете вы, можно взять и другие фреймворки. Соглашусь. Но мы отдали свое предпочтение именно RoR, как самому простому и быстрому варианту. Минимум затрат и прекрасная результативность.
Если у вас есть советы или рекомендации, буду рада с ними ознакомиться. Спасибо!xenm
08.08.2017 23:28Хотелось бы больше технических моментов. Например, реализация характеристик, опций товаров. Как у вас на rails это реализовано, какие плюсы.
IrynaKorkishko Автор
09.08.2017 16:44Как пример могу привести HelloCare:
http://syndicode.co/project-archive/hellocare-everyday-helpers-services-marketplace-with-ruby-on-rails/
Это двухсторонний маркетплейс формата peer-to-peer. При его разработке мы создали два отдельных приложения: для тех, кто нуждается в помощи, и для тех, кто ее предоставляет.
Для этого маркетплейса мы реализовали следующий функционал (помимо промо-сайта с лендинговыми страницами):
- Регистараця клиента и отдельно регистарция поставщика услуг.
- Листинг. Процесс выбора услуги с показом профилей ближайших помощников (поставщиков услуг) на основе их локации. Так же в листинге мы разработали систему рейтинга для помощников и календарь, когда они могут выполнять заказы.
- Процесс заказа услуги, где клиент может знакомиться более детально с каждым профилем предлагаемого помощника. Также, во время заказа клиент должен заполнить регистрационную форму.
- Дата, время заказа и оплата появляются только в конце процесса заказа.
- Верификация документов.
- Процесс оплаты. Здесь мы реализовали схему с графиком оплаты платежей.
- Backend платформа для администратора, который должен контролировать всех клиентов и помощников.
- Интеграция с различными внешними системами платежей, социальными сетями, почтовыми сервисами, пуш-уведомления. Если быть точным, то следующие интеграции: PayPal, Google Firebase, Sendgrid, Google Geocoder&Map API, Facebook и Google+ login APIs.
Для данных использовали PostgreSQL и Redis. Больше технологий вы найдете в самом кейсе, линк на который я предоставила в начале.
Если же говорить о классическом "товарном" маркетплейсе, то могу привести пример Woobra: http://syndicode.co/project-archive/woobra-ruby-on-rails-marketplace-for-product-sourcing/
Этот маркетплейс В2В типа, двухсторонний. Интеграции и технолгии также указаны по линку.
Плюсы для маркетплейсов в целом — это то, что рельсы действительно универсальны. Их логика и архитектура позволяет сэкономить время на простых задачах. С ними очень просто и быстро можно построить примитивный прототип, а у же на его основе создать что-то действительно интересное и уникальное. И это очень спасает тайминг любого проекта, позволяя потратить больше времени на что-то более сложное, чем базовый функционал.
eoffsock
08.08.2017 11:16+1Как редактор, кратко расскажу, в чем проблемы статьи. Их две.
Во-первых, вы не изучили аудиторию. Тут половина знает, что такое рельсы, а вторая половина способна моментально нагуглить и понять, что это такое. Дайте технические подробности, а не общие слова про простоту разработки и активное сообщество разработчиков.
Во-вторых, статья не про рельсы получилась, а немного про маркетплейсы. Про рельсы тут только то, что они есть и они прикольные. Про маркетплейсы тоже общие слова без полезной информации. Таким образом, заголовок — обман, а обманывать нехорошо.
Относительно простой рецепт, как написать неплохую статью на вашу тему:
Ищете реальный и желательно личный опыт по теме. Ваша компания разрабатывала маркетплейс на рельсах? Опрашиваете всех причастных, выясняете технические детали, проблемы и их решения. Договариваетесь, что пришлете черновик и попросите посмотреть, все ли нормально с технической стороны.
Собираете все вместе, делаете нормальную структуру. Черновик рассылаете тем, с кем договорились, читаете отзывы, закрываете замечания.
Редактируете, публикуете. На выходе — статья с минимумом слов о маркетплейсах и максимумом технических деталей и решенных проблем, которые интересны аудитории. Лайк, шер, овации.
IrynaKorkishko Автор
08.08.2017 11:20+1Спасибо! Ваш комментарий полезен для меня! Постараюсь учесть ваши советы на будущее.
asvechkar
10.08.2017 00:42Честно говоря думал увидеть здесь пример проекта с отрывками кода и рекомендациями по хранению корзины.
«Жаль, что мы так и не услышали начальника транспортного отдела ...».
Предлагаю автору не останавливаться на достигнутом и опубликовать еще несколько статей на эту тему:
- «Django для разработки маркетплейса».
- «Loopback.js для разработки маркетплейса».
- «Laravel/Symfony для разработки маркетплейса».
- ...
- «Any framework для разработки маркетплейса».
Достаточно в статье заменить название фреймворка.
Если серьезно, то интересно узнать опыт нагруженных интернет-магазинов / маркетплейсов, где в качестве бэкенда пусть будет и Rails, а фоновые сервисы написаны, например, на Golang.
IrynaKorkishko Автор
10.08.2017 10:53Отрывков кода не обещаю, как, впрочем, и статей про разработку маркетплейсов на Django или Laravel. В силу того, что мы работаем с рельсами, и считаем их лучшим вариантом "затраты/время/результат". Однако, ваш комментарий несомненно пойдет мне на пользу: статья про опыт наших нагруженных маректплесов в будущем очень вероятна. Спасибо!
Tonkonozhenko
Я так и не понял как вы делали, разрабатывали с нуля или на основе spree/sharetribe?
IrynaKorkishko Автор
Здравствуйте! Мы разрабатывали с нуля.