Pull to refresh
0
0

Пользователь

Send message

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

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


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

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

Здравствуйте! Мы разрабатывали с нуля.

Information

Rating
Does not participate
Registered
Activity