Pull to refresh

Comments 14

Я так и не понял как вы делали, разрабатывали с нуля или на основе spree/sharetribe?

UFO landed and left these words here
Моя статья рассказывает про маркетплейсы: их виды, специфику, функционал. Поэтому логично, что я рассматриваю использование рельсов конкретно под создание маркетплейсов. Это да.
Если же говорить про различные веб и мобильные приложения, то руби он рейлс тоже подходит и для большинства из них. Но всегда нужно исходить из специфики проекта. Ограничивать себя исключительно рельсами, разумеется, глупо.
Как я и упоминала в начале, статья базируется на опыте нашей компании, которая занимается разработкой маркетплейсов (не только, конечно, но в значительной мере). В контексте этого я и рассказываю, почему мы используем именно RoR для создания маркетплейсов. Почему это удобно, быстро и относительно просто.

Ниачем :)

Для разработки с нуля используются различные фреймфорки

Если квалификации хватает, то можно и на голом языке (PHP). В нем есть все нужное. :)
Можно хоть и на РНР. Вопрос в том, стоит ли овчинка выделки. Но мы не про язык, а про фреймфорк. С рельсами уже имеется проторенный путь, стоит только конфигурировать необходимые части — и все готово.
Изощряться, впрочем, можно по-разному. Писать на РНР может и студент, конечно. Дело не в том.
Возвращаясь к фреймворку, с рельсами программисту будет значительно проще, поскольку там уже достаточно готовых для использования вещей. К тому же предпочтения языка программирования — всего лишь дело вкуса. Например, многие предпочитают руби только потому, что его синтаксис понятен без лишних обяснений. Что делает работу легче и приятнее.
Так что комментарий, простите, «ниачем».
Из статьи совершенно не понятно, почему RoR прекрасно подходит для создания онлайн маркетплейсов.
Здравствуйте!
RoR прекрасно подходит для создания маркетплейсов, в первую очередь, потому, что с ним создать маркеплейс можно очень быстро. Заказчики нашей компании обычно нуждаются в готовом продукте или работающем прототипе «вчера». Поэтому времени на то, чтобы искать новые пути создания, нет. Использовать готовые решения тоже не вариант, поскольку необходимой кастомной конфигурации из них не слепишь. И в результате все обойдется дороже, дольше и не так, как того хотел заказчик.
Поэтому остается вариант с разработкой с нуля, чтобы все сразу было создано так, как нужно. И здесь есть проторенные дорожки с готовыми решениями руби он рейлс. Их достаточно просто конфигурировать, доработать, внести изменения — и вуаля.
Конечно, скажете вы, можно взять и другие фреймворки. Соглашусь. Но мы отдали свое предпочтение именно RoR, как самому простому и быстрому варианту. Минимум затрат и прекрасная результативность.
Если у вас есть советы или рекомендации, буду рада с ними ознакомиться. Спасибо!
Хотелось бы больше технических моментов. Например, реализация характеристик, опций товаров. Как у вас на rails это реализовано, какие плюсы.

Как пример могу привести 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В типа, двухсторонний. Интеграции и технолгии также указаны по линку.


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

Как редактор, кратко расскажу, в чем проблемы статьи. Их две.

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

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

Относительно простой рецепт, как написать неплохую статью на вашу тему:

Ищете реальный и желательно личный опыт по теме. Ваша компания разрабатывала маркетплейс на рельсах? Опрашиваете всех причастных, выясняете технические детали, проблемы и их решения. Договариваетесь, что пришлете черновик и попросите посмотреть, все ли нормально с технической стороны.

Собираете все вместе, делаете нормальную структуру. Черновик рассылаете тем, с кем договорились, читаете отзывы, закрываете замечания.

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

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

Предлагаю автору не останавливаться на достигнутом и опубликовать еще несколько статей на эту тему:
  • «Django для разработки маркетплейса».
  • «Loopback.js для разработки маркетплейса».
  • «Laravel/Symfony для разработки маркетплейса».
  • ...
  • «Any framework для разработки маркетплейса».


Достаточно в статье заменить название фреймворка.

Если серьезно, то интересно узнать опыт нагруженных интернет-магазинов / маркетплейсов, где в качестве бэкенда пусть будет и Rails, а фоновые сервисы написаны, например, на Golang.

Отрывков кода не обещаю, как, впрочем, и статей про разработку маркетплейсов на Django или Laravel. В силу того, что мы работаем с рельсами, и считаем их лучшим вариантом "затраты/время/результат". Однако, ваш комментарий несомненно пойдет мне на пользу: статья про опыт наших нагруженных маректплесов в будущем очень вероятна. Спасибо!

Only those users with full accounts are able to leave comments. Log in, please.