Всем привет. Меня зовут Владимир, я уже более 4,5 лет работаю в компании NAUMEN в должности инженера-программиста. В свободное от работы время, я создаю свои мини-проекты, в частности, мобильные приложения и игры.

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

Надеюсь, вы понимаете, что ради такой «банальщины», статью на Хабр я бы писать не стал. Особенность моего проекта в том, что я воспользоваться программным обеспечением нашей компании не по прямому назначению. Возможно, мой опыт натолкнет вас на эксперименты и поиски нестандартных применений уже известного софта под рукой. Предлагаю вместе сравнить стандартные подходы к разработке с моим опытом и понять, стоило ли экспериментировать или нет.

О приложении

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

Что нужно для запуска приложения?

Для того, чтобы запустить приложение мне нужны: Android-приложение в качестве оболочки для данных, back-end приложение, cервер или пространство для back-end приложения.

Помимо технических характеристик, важно учесть следующие моменты:

Во-первых, как истинный программист — я ленив, а значит, хочу сделать все как можно быстрее, но без потери качества. Во-вторых, как экономный человек я предпочитаю сделать все бесплатно, ну или за минимальную стоимость, но как умный человек, я также понимаю, что мое потраченное время тоже деньги! В-третьих, мне важно, чтобы админ-панелью было удобно пользоваться контент-менеджерам, которых я бы хотел поискать на сайтах фриланса, чтобы наполнить базу. (Спойлер: им было удобно работать).

Само мобильное приложение (я буду далее называть его фронтом), я писал на Java в android studio. Его разработка оказалась легкой и даже примитивной, я просто нашел статьи про создание списков (ListView) в android-приложении и все. В обоих случаях будет использоваться одна оболочка. У меня не было цели сделать красиво и круто сразу на прототипе.

Считаем время на разработку

Теперь вернемся к back-end`у. В классическом варианте я использовал ruby on rails. Просто потому, что я на нем умею программировать и знаю, как сделать внятное приложение, и быстро смогу его собрать.

Для ROR-приложения необходим либо свой сервер, либо хостинг, например, digital ocean (DO) или Heroku. Тут не принципиально, все на ваш вкус.

Поскольку для создания pet-проектов временной ресурс ограничен, важно посчитать, сколько времени уйдет на то, чтобы сделать такой сервис:

Нужно два объекта: «Город» и «Место/Локация» — минут 30.

Использование загружаемых картинок я выношу отдельно, так как если просто использовать хранение на серверах DO, то мы быстро выйдем за пределы бесплатного доступа. Оно того не стоит, зато быстро сделаем — минут 10-15. Если надо хранить в гугле или amazon-серверах, то делать с ними интеграцию будет немного больше, оценим в минут 30.

Верстка меня немного удручает, чтобы корректно её накидать простыми view — уйдет минут 10. Но мне же важно, чтобы контент-менеджерам было удобно пользоваться, поэтому надо подключить bootstrap или material-UI — оценим в 20-30 минут. Версию с отдельным фронтом и написанием на react я вообще не рассматриваю, потому что у меня нет достаточного опыта, чтобы быстро все делать, да и проект не настолько крутой, чтобы вкладывать в него столько ресурсов.

Настройка API для передачи данных в мобильное приложение. В 5 версии RAILS gem rails-api стал частью ядра. Накидать быстро контроллер на каждый объект, построить маршруты дополнительно под API — 30-40 минут.

Если писать тесты еще сверху на объекты и API, то можно все время смело увеличить в два раза.

Закинуть на гитхаб и в DO или Heroku еще минут 20.

Итог: для классического back-end приложения я в лучшем случае потрачу минимум 130 минут (с тестами 250 минут), чистого времени! Но так как я делаю мобильное приложение в свободное время, найти полтора-два часа практически невозможно, поэтому, скорее всего, будет потрачена неделя физического времени.

Получилось как-то сложно и муторно. Столько усилий и времени, чтобы запустить приложение, которое может и не выстрелит и будет пылиться на просторах google play? А если и выстрелит, то потом мне надо будет потратить еще столько же часов на доработку приложения, улучшения, сбор статистики, новые страницы в админке, в которых надо смотреть на статистику и на опубликованные статьи?

Разработка на основе Service Management Platform

Начал искать, какие решения в сети есть для ускорения написания back-end`a, а также чтобы еще и в API умел. Оказывается, есть такое понятие как BaaS — Backend-as-a-Service. Я нашел несколько популярных вариантов:

• Firebase,

• AWS,

• Parse,

• Back4App.

В этот момент я задумался, а можно ли посмотреть на продукт SMP нашей компании, как на BaaS. Обычно SMP используется для организации сервисного обслуживания, обработки заявок и построения всяческих отчетов, но почему бы не попробовать собрать на её основе приложение?

Сел также считать, сколько мне понадобится времени:

Создать два объекта с нужными атрибутами — минут 5.

Вывести атрибуты на форму создания и на карточки — минут 5. Без преувеличения, мы просто берем и указываем, какие группы атрибутов нам показывать на той или иной странице.

И всё, пункты-то кончились. API, работа с картинками и их хранение идут из коробки. Тесты писать не надо. Настройка карточек мгновенная.

Минусы, конечно, тоже есть:

• Мы ограничены текущей визуальной составляющей.

• Мы не можем указывать свои маршруты для API.

• Чтобы отображать графики, надо подключить дополнительный платный модуль «Дашборды».

Они меня не смущают, так как полностью покрывают мои сэкономленные часы работы сейчас и в будущем.

Подводим итоги

Так как основной проблемой стал временной ресурс, я остановился на втором варианте. Собрал приложение за один вечер и остался доволен: все запустилось быстро и, гипотезу актуальности приложения можно проверить в 1 клик.

Платформа достаточно гибкая, поэтому в будущем можно увеличить функционал мобильного приложения авторизацией, добавлением мест в избранное, рейтингов от пользователей, подключением интерактивных карт на страницу объекта, возможно еще и комментирование. Это все можно сделать в рамках SMP.

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

Ознакомиться с приложением в Google Play

В моем случае, SMP покрывает две из трех основных задач, которые решает BaaS: скорость развития и мультиплатформенность. В комментариях, предлагаю пообщаться: согласны ли вы с моими выводами? Также делитесь, какие системы вы используете не по прямому назначению и какой ощутимый эффект вы от этого получаете.