Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Зачем нужен Ruby on Rails? Или как работает стартап Skyworker

Недавно я запостил видео, где знакомил тусовку с продуктом, который мы строим. Сразу налетела куча вопросов «Почему Ruby on Rails в 2020-м то году?»
При выборе технологий многое зависит от контекста и задач, которые должны быть решены. Отвечаю тут на вопросы «что», «почему», «для чего» и «как» одним топиком.

Контекст был такой: в декабре 2019 года мы начали разработку приложения Skyworker, которое мониторит варианты работы под требования специалиста.
Нам нужно было за 1 месяц силами 2-х разработчиков написать альфу продукта, с которой можно было бы тестировать бизнес идею и собирать фидбек. Уже есть бета, ее можете посмотреть тут.

RoR Рик и Морти

Задачи стояли такие:

1. Создать клиент-серверное приложение, которое работает согласно restful принципам, и которое в перспективе будет иметь мобильную версию.
2. Разработать data driven систему, в которой можно легко создавать и изменять данные на админ стороне.
3. Построить приложение с большим количеством связей между сущностями.
4. Приложение должно поддерживать разные роли пользователей.

Решение на Backend
Частично работа уже была начата на RoR и у нас был выбор — переходить на более современный Node.js, в котором у нас больше экспертизы, или продолжать писать на RoR.

Сроки и ресурсы были сильно ограничены и перевес пошел в сторону Ruby on Rails, потому что:
1. Была супер важна скорость написания кода. C RoR мы получили быструю генерации роутов, контроллеров, моделей, миграций. Одной строчкой кода мы строим дефолтное поведение, что для стартапа всегда важно.
2. Есть возможность легко управлять большим количеством данных на стороне администратора. Нам нужна была админка, потому что, как для пользователей ИТ специалистов, так и для ИТ компаний есть большое количество классификаторов, которые нужно заполнять, менять, расширять. Задачи не сложные и мы получаем функционал за считанные минуты, если используем RoR, так как существует большое количество сторонних библиотек, которые предоставляют подобный функционал.
3. Тебе не важно, с каким провайдером ты работаешь. На все есть фасады из-под капота. Тут имеется готовая абстракция для работы с базой данных и можно не переживать, что у тебя PostgreSQL или MySQL. Такая же ситуация для работы с отложенными задачами, а ведь подобная малая связанность компонентов важна при создании MVP

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

Решение на Frontend:
У нас single page application. Выбор стоял между React+Redux и Angular.

1. Об этом спорить можно вечно, но выбрали React, поскольку у нас именно там сильная экспертиза.
2. Взяли next.js, чтобы быстро построить архитектуру фронт части и подготовить ее для SSR. Нужно это, так как продукт будет доступен неавторизованным пользователям и все поисковые движки оптимизируют свой поиск именно под такие приложения — потому это важное long-term решение.
3. Была задача построения многослойной архитектуры, чтобы исключить зависимость API от UI контракта. Потому тот UI, который делаем в бете — это оболочка для тестирования бизнес идеи, а уж как это выглядит — не особо важно на первом этапе. Сейчас уже UI эксперт строит нам design language, который можно легко имплементировать и с наименьшим количеством изменений и не менять слой работы с данными.
4. На этапе проектирования заложили возможность работы с инструментами для сбора аналитики и последующего проведения A / B тестирования.
5. Выбрали Material UI, который достаточно продуманный и сократил нам время на построение компонентов представления.

В сумме получается, что у нас на борту Ruby on Rails и React.js + Redux + Next.js, у которых есть большие комьюнити и возможность воплотить все, что я тут перечислил. Мы построили структуру, которая позволяет быстро трансформироваться, в зависимости от изменения продуктовой логики или бизнес модели в целом, а мы стартап и нам это нужно.

Надеюсь, ответил) Живите долго и процветайте! Пользуйтесь продуктом, в июне выкатим релизную версию.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Завантажується дуже повільно із-за hotjar аналітики яка підключається 4.5 секунди до показу контенту

Комусь ще писали в LinkedIn і рекламували цей ресурс в повідомленні?

Зачем нужен Ruby on Rails?

Чтобы трудоустраивать рубистов из Днепра, очевидно же.

Сразу налетела куча вопросов «Почему Ruby on Rails в 2020-м то году?»

Про кучу вопросов пишут всегда, вот всегда, именно в таком ключе, когда на самом деле 1.5-2 человека спрашивали.

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

Однако, у меня вопрос — какие средства деплоя и хоста вы используете и почему?

Спасибо! Тоже было интересно, почему люди выбирают Ruby.

В целом я тут не вижу ничего из вашего кейса, что нельзя было бы сделать с такой же легкостью на linux + asp.net core + postgresql : в целом все что вы описали: из коробки роутинг, аутентификация (3rd party, etc), Identity Server (выдает jwt-токены на любое устройство), EntityFramework — там и O/RM + миграции. Можно было сделать в виде монолита с горизонтальным или даже вертикальным масштабированием. После повышения нагрузки — переписать часть кода на чистый SQL.
В целом этот стек абсолютно бесплатный и специалистов больше.

Единственное, пожалуй, чего не хватает в экосистеме asp.net — это генераторы crud-админок на основании сущностей EF. Я не находил нормальных коммерческих продуктов.Если кто-то знает таковые — дайте знать. Но написать подобную вещь используя готовые контролы UI либы для полностраничного рендеринга(чтобы не париться) довольно тривиальная задача.

На жабе тоже можно все просто сделать..
Но, у них был выбор нода или рельсы )

Нужно это, так как продукт будет доступен неавторизованным пользователям

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

Подивився, сподобалось, але грузиться повільно, а ще хочу дізнатись, чи є у вас відкрита класифікація доменів як ось?

Чи буде можливість подивитись вакансії на карті?

Спасибо что расписали все, но не было же ответа? Все что я прочитал это то, что часть уже была написана на Руби, а почему Руби выбрали чтобы написать эту часть которая уже была я так и не увидел.

Привет! А что насчет вот этой части? Это и есть те самые факторы, которые повлияли на решение.

Сроки и ресурсы были сильно ограничены и перевес пошел в сторону Ruby on Rails, потому что:
1. Была супер важна скорость написания кода. C RoR мы получили быструю генерации роутов, контроллеров, моделей, миграций. Одной строчкой кода мы строим дефолтное поведение, что для стартапа всегда важно.
2. Есть возможность легко управлять большим количеством данных на стороне администратора. Нам нужна была админка, потому что, как для пользователей ИТ специалистов, так и для ИТ компаний есть большое количество классификаторов, которые нужно заполнять, менять, расширять. Задачи не сложные и мы получаем функционал за считанные минуты, если используем RoR, так как существует большое количество сторонних библиотек, которые предоставляют подобный функционал.
3. Тебе не важно, с каким провайдером ты работаешь. На все есть фасады из-под капота. Тут имеется готовая абстракция для работы с базой данных и можно не переживать, что у тебя PostgreSQL или MySQL. Такая же ситуация для работы с отложенными задачами, а ведь подобная малая связанность компонентов важна при создании MVP

Интересно! Спасибо, что поделился!

Подписаться на комментарии