Comments 14
Я так и не понял как вы делали, разрабатывали с нуля или на основе spree/sharetribe?
Если же говорить про различные веб и мобильные приложения, то руби он рейлс тоже подходит и для большинства из них. Но всегда нужно исходить из специфики проекта. Ограничивать себя исключительно рельсами, разумеется, глупо.
Как я и упоминала в начале, статья базируется на опыте нашей компании, которая занимается разработкой маркетплейсов (не только, конечно, но в значительной мере). В контексте этого я и рассказываю, почему мы используем именно RoR для создания маркетплейсов. Почему это удобно, быстро и относительно просто.
Для разработки с нуля используются различные фреймфорки
Если квалификации хватает, то можно и на голом языке (PHP). В нем есть все нужное. :)
Изощряться, впрочем, можно по-разному. Писать на РНР может и студент, конечно. Дело не в том.
Возвращаясь к фреймворку, с рельсами программисту будет значительно проще, поскольку там уже достаточно готовых для использования вещей. К тому же предпочтения языка программирования — всего лишь дело вкуса. Например, многие предпочитают руби только потому, что его синтаксис понятен без лишних обяснений. Что делает работу легче и приятнее.
Так что комментарий, простите, «ниачем».
RoR прекрасно подходит для создания маркетплейсов, в первую очередь, потому, что с ним создать маркеплейс можно очень быстро. Заказчики нашей компании обычно нуждаются в готовом продукте или работающем прототипе «вчера». Поэтому времени на то, чтобы искать новые пути создания, нет. Использовать готовые решения тоже не вариант, поскольку необходимой кастомной конфигурации из них не слепишь. И в результате все обойдется дороже, дольше и не так, как того хотел заказчик.
Поэтому остается вариант с разработкой с нуля, чтобы все сразу было создано так, как нужно. И здесь есть проторенные дорожки с готовыми решениями руби он рейлс. Их достаточно просто конфигурировать, доработать, внести изменения — и вуаля.
Конечно, скажете вы, можно взять и другие фреймворки. Соглашусь. Но мы отдали свое предпочтение именно RoR, как самому простому и быстрому варианту. Минимум затрат и прекрасная результативность.
Если у вас есть советы или рекомендации, буду рада с ними ознакомиться. Спасибо!
Как пример могу привести 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. В силу того, что мы работаем с рельсами, и считаем их лучшим вариантом "затраты/время/результат". Однако, ваш комментарий несомненно пойдет мне на пользу: статья про опыт наших нагруженных маректплесов в будущем очень вероятна. Спасибо!
Ruby on Rails для разработки маркетплейса