Разработка бэкенда мобильного приложения на стороне студии: почему это выгодно

Что такое бэкенд и когда он нужен

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

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

Серверная часть (бэкенд) — это компьютер с работающей на нём программой для обработки данных. Как и мобильное приложение, эта программа тоже является кодом и его тоже нужно программировать. Приложение интернет-магазина, такое как разработанные в Лайв Тайпинг ИЛЬ ДЕ БОТЭ или Sephora, не может существовать без бэкенда, отвечающего за представление данных по товарам, учёт, формирование заказа и проведение оплаты.

Хороший бэкенд обладает:

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

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

Что такое API

API (Application Programming Interface) — это часть бэкенда, играющая роль языка общения между сервером и клиентом (в нашем случае — с мобильным приложением). API служит для представления серверных данных в формате, удобном для этого общения.

Когда мы говорим «API мобильного приложения», мы имеем в виду не только формат представления данных, но приложение, которое берёт данные, обрабатывает их и отдаёт клиенту в этом формате. Когда мы говорим «пишем API», это значит, что мы программируем бизнес-логику, пишем документ и придумываем сами форматы.

Для хорошего API характерны:

• следование общим принципам разработки,
• актуальная и полная документация,
• стабильность работы,
• быстрое время ответа на запрос от клиента,
• версионирование.

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

Почему заказ бэкенда у студии мобильной разработки повысит качество продукта и снизит бюджет

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

Качество и стоимость процесса создания мобильного приложения стоят на трёх аспектах отношений команд мобильной и бэкенд-разработки.

Стандартизированные процессы

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

Стандартизация помогла нам сэкономить время на написании таймера для ограничения количества отправленных СМС при регистрации. Впервые мы сделали его для приложения Киноголик, а позже воспроизвели в приложении Мой Доктор.

Ограничить время отправки важно по двум причинам:

1. За СМС платит владелец приложения, и многократное нажатие кнопки «отправить» разоряет его.
2. СМС доставляются с задержкой. Если запросить много кодов подряд, то они придут разом и запутают пользователя.

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

• Если злоумышленник взломает приложение, или кнопка отправки зависнет, а таймер сбросится, то бэкенд всё равно не позволит отправлять СМС до истечения времени.
• Если пользователь закроет приложение и снова откроет, то бэкенд отправит приложению оставшееся количество секунд до повторной отправки СМС и пользователю не придётся ждать всё время сначала.
• Во время тестирования время на таймере можно установить поменьше, а если у провайдера проблемы, то побольше.

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

Если на каждом проекте, где есть такой таймер, принцип передачи информации будет разным, то задача каждый раз будет отнимать большое количество часов. Наши команды мобильной и серверной разработки стандартизировали этот процесс, чем и ускорили его. В этом одно из преимуществ, которое вы получите, если закажете бэкенд-разработку у нас. Расскажите о своём проекте, и мы вас бесплатно проконсультируем.

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

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

Все эти технические неурядицы звучат для наших клиентов одинаково: сроки горят, а деньги уходят не туда. Решить значительную их часть можно, когда обе команды рядом.

Быстрая и доверительная коммуникация

Есть две команды, совершенно не знающие характеров друг друга, не имеющие общих интересов и не общающиеся на обедах и перекурах. Сколько времени им потребуется, чтобы сработаться? Похожий пример: будь у вас финансовые проблемы, кто быстрее вошёл бы в ваше положение — первый встречный или родственники и ближайшие друзья?

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

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

• В одном из приложений есть кнопка для отмены подписки. Сторонние бэкенд-разработчики решили изменить интерфейс метода отписки от рассылок, но не поставили нас в известность. Работа клиента и сервера рассинхронизировалась, поэтому письма продолжали приходить пользователям. Кнопка не работала 3 месяца, что привело к гневным отзывам от пользователей и удару по имиджу компании.
• Пользователи не могли сделать через приложение заказ на адрес, включающий знак «/». Чтобы сервер перестал считать их невалидными, бэкенд-команде нужно было вставить этот знак в регулярное выражение в коде, которое проверяет адреса. Между обнаружением проблемы и её решением прошла неделя — достаточно, чтобы потерять какое-то количество пользователей.
• Перед нами был выбор: своими силами внести правки в приложении или дождаться буквально одной манипуляции от серверных разработчиков. Когда ждать было больше нельзя, мы приняли меры, но финансовые издержки неприятно впечатляют: оплата работы iOS и Android-разработчиков, полный регресс, тестирование, релиз — за всё это платит клиент.

Когда команды работают по одну сторону, они находят решение без стресса, споров и необходимости зарабатывать авторитет в глазах друг друга. В то же время в руках менеджеров находятся рычаги давления, которых они лишены, когда команда удалённая. Всё это ускорит темпы работы над вашим проектом.

В ситуациях, когда бэкенд-разработчик затягивает с результатом, но показать работу продукта нужно, мы можем создать mock-сервер. Это имитация запросов от приложения и ответов от сервера через json-объекты, зашитые в мобильном приложении. Структура таких объектов опирается на то, что написано в составленной аналитиком документации. Метод выручает при разработке MVP и при параллельной разработке приложения и бэкенда, но важно знать, что время уходит на написание кода, который станет бесполезным, когда сервер заработает. Поэтому, чтобы не растягивать бюджет, мы предлагаем клиенту заморозить разработку завязанной на бэкенде функциональности и взять другую задачу.

Актуальная документация

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

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

Те же трудности могут испытать мобильные разработчики студии, когда будут интегрироваться с бэкендом, сделанным на стороне. Устаревшая документация — результат человеческого фактора: не все изменения вносятся своевременно. Любой связанный с этим конфуз команды, находящиеся по одну сторону, решают диалогом. Но если вы захотите передать проект, разработанный у нас, на поддержку другой студии, то можете быть уверены: вы получите документацию, в которой разберётся иновичок.

Что помогает нам в работе

Гладкое взаимодействие между отделами мобильной и бэкенд-разработки было бы невозможно без важных инструментов и методологий, ставших стандартными для процессов. Когда есть стандартизация, разработчик выполняет задачу быстрее, а время выполнения задачи более предсказуемо и обходится дешевле.

• При написании API мы придерживаемся общепринятой архитектуры REST. Это позволяет разработчикам интуитивно понимать работу API.
• Для повышения качества кода у нас отлажен процесс код-ревью. Его смысл в том, чтобы любые изменения, вносимые программистом, попадали в основное хранилище кода и в релизную версию приложения только после того, как их проверят остальные участники команды. Качественный код лучше воспринимается даже теми разработчиками, которые прежде не работали на проекте, проще улучшается и изменяется, лучше поддерживается и тестируется. Подробнее о том, что такое код-ревью, читайте в статье нашего аналитика.
• Для описания документации мы используем сервисы, например, Apiary и Swagger. С ними документация читается просто, а пишется быстро.
• Для автоматизированного запуска тестов и сборки приложения используем принцип Continuous Integration. Он освобождает нас от ручной работы и уменьшает количество ошибок, которые мог бы допустить разработчик.
• Для быстрых и регулярных релизов у нас отлажен процесс автоматизированного деплоя, то есть запуска кода для выполнения новой версии программы на сервере. Чтобы не делать это вручную, мы используем специальные скрипты. С автоматизацией снижается риск ошибки и тратится меньше времени. Это значит, что каждый деплой обходится для вас дешевле.

Закажите бэкенд-разработку в студии Лайв Тайпинг

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

Компания Live Typing занимается проектированием, дизайном и разработкой мобильных приложений и веб-сервисов. Мы создаём и поддерживаем цифровые продукты для стартапов, автоматизируем и выводим в мобильную среду существующий бизнес, выручаем из беды проекты, которым не повезло с предыдущими подрядчиками. Основное направление компании — создавать и заботиться о eCommerce и Retail-проектах, но мы также имеем опыт работы в индустриях Publishing, Fashion, Travel, Health, Civic, Events, Technology, Art, IoT, Education, Uber-like, Fintech.

Для серверной разработки мы используем язык PHP и фреймворки Laravel и Yii.

В 2019 году мы занимались разработкой и развитием API для приложений магазинов парфюмерии и косметики ИЛЬ ДЕ БОТЭ и Sephora, приложения для программы лояльности Лояка, приложения для контроля здоровья и получения медицинских рекомендаций Diagnost, приложения для покупки абонементов в кино Киноголик, приложение для чтения статей из «Блога Касперского» Kaspersky Security Pulse и мобильного сервиса для медицинских консультаций Мой Доктор.