бэкенд для мобильного приложения
Топовый стек: Backend и Frontend для мобильного приложения
Мини-обзор без референсов
Ingredients
Directions
Node.js (бэк) + React Native (фронт)
Одна из наиболее сильных связок в качестве стека для разработки приложения. React Native — это кроссплатформенный фреймворк, который можно отнести к флагману мобильного девелопмента. С его помощью были написаны или переписаны на React. Между прочим, инста — это настоящий хайлоад : за один месяц приложение посещает 1 миллиард активных пользователей, более 500 миллионов используют его ежедневно. Даже Tesla использует этот фреймворк для мобильного приложения по управлению автомобилем
Мобильное приложение React с API-интерфейсом Node.js работает через Java Scrtipt как на веб-интерфейсе, так и на бэкенде. Это позволяет писать действительно нативные приложения — React переводит весь написанный JavaScript-код на «родной» язык конкретного устройства, например Java на Android или Objective-C на iOS, а для стилизации можно использовать даже CSS-код
Python (бэк) + Kotlin (фронт)
Довольно интересная связка, где в качестве бэка используется Python (работа с БД), и языком программирования Kotlin в качестве графической оболочки (GUI). В Pynhon есть бесплатные фреймворки для разработки мобильных приложений (Kivy или Beeware), но как «фронт» питон для программирования UI приложений не очень удобен (здесь как раз подойдет Kotlin), зато его можно задействовать в бэкенде, т.к язык располагает к жонглированию больших объёмов данных и применению машинного обучения (не зря же его используют в Data Sciense).
Один из самых известных фреймворков Django как раз написан на Python
Котлин же как раз очень удобен в плане разработки интерфейса, благодаря user-friendly синтаксису и получивший полную поддержку установочных пакетов Google и IDE, включая Android и SDK.
Laravel + Flutter
Флаттер — крутой инструмент разработчика UI для создания красивых и нативных приложений на всех платформах — десктоп, мобайл, веб. Среда Flutter используется как единая база кода, которая компилируется в собственный код для iOS и Android. Flutter довольно давно снискал популярность среди западных front-end разработчиков. У нас же в стране хоть и хвалят его за упрощенный процесс верстки, но пока не пользуется большим спросом.
Lavarel — фреймворк, работающий на бэке. С его помощью, используя API, можно писать «классические» серверные функции — учетные записи пользователей, управление заказами и т.д.(например, авторизация делается с помощью Laravel Passport). Он имеет открытый исходный код и имеет ряд функций для упрощения разработки и автоматизированными тестами.
Как организовать бэкенд мобильного приложения?
Что мы делаем? Сервис регистрации и авторизации пользователя для мобильного приложения
В пет-проектах каждого мобильного разработчика рано или поздно наступает момент, когда требуется быстро и без лишней головной боли создать сервер для своего приложения. Не важно, какую функцию должен выполнять сервер: будь то хранение данных или регистрация/авторизация пользователей.
Как правило, вначале все идут (ну или большинство) по пути наименьшего сопротивления. Мы ищем готовое решение и смотрим, как быстро его можно приспособить для наших нужд.
На данном этапе первое, что получается «нагуглить» — это сервисы Firebase, бесплатных лимитов которых более чем достаточно для организации бекенда небольшого мобильного приложения. Но в данном случае, рассматривая именно российского разработчика, мы рискуем наступить на грабли нашего законодательства — трансграничную передачу данных и хранение персональных данных пользователя.
(ФЗ 152 «О персональных данных», ст. 12, Глава 2)
Соблазн использования именно Firebase велик, но если мы хотим застраховаться от ненужной возни с различными надзорными ведомствами, то начинаем смотреть альтернативные варианты.
Следующий этап — это использование VDS-сервера с каким либо open-source или freemium решением, где за основу берется готовый «сервис-как-услуга» или решение, позволяющее развернуть похожий функционал.
Несколько лет назад на Хабре я уже писал подробное руководство по настройке BaasBox (статья была убрана из паблика по причине устаревшей информации) на арендованном сервере и приводил пример использования различных вызовов в iOS-приложении для языка Objective C. Но BaasBox реально «тяжеловес» и диктует свой минимум для арендуемого сервера. Немного поигравшись с ним, было решено использовать другое решение. Parse-server на тот момент только недавно был отдан в open-source разработку компанией Facebook, не имел столь большого количества адаптеров, как в настоящее время, но его возможностей было более чем достаточно для личных проектов и приложений частных заказчиков (многие проекты до сих пор существуют и стабильно работают).
Справедливости ради, стоит отметить, что parse-server очень сильно повзрослел и активно развивается. На текущий момент воссоздан практически весь функционал, что был доступен в коммерческом предке. Можно писать свои хуки, локализованные пуш-уведомления, менеджер процессов и есть даже подписка на изменение объектов, основанная на сокетах (ParseLiveQuery — если будет интересно, напишу отдельно статью по настройке ParseLiveQuery).
Но parse-server перестал быть интересен именно в тот момент, когда потребовалось реализовать нестандартный тип данных, с которым сложно работать на основе определенных в системе типов. Также мешает то, что не являясь профильным серверным разработчиком, ранее я не придавал значения более эффективному развертыванию окружения и многие файлы конфигураций делались руками, при этом действия постоянно повторялись на каждом новом сервере. Именно в этот момент и приходит понимание, что коробочное решение — это не решение всех проблем, и следует переходить к следующему этапу организации своего сервера для мобильного приложения.
В последнее время мой основной язык разработки — Swift. Поэтому именно он и интересен мне в первую очередь в написании серверного кода. Сам по себе язык Swift легко установить на unix-системе, но это не даст никаких явных преимуществ. По своей сути это будет напоминать разработку консольного приложения со сложной логикой. Придется много времени потратить на воссоздание базовых методов, необходимых в работе сервера.
Как и во многих других языках, server side swift имеет свои фреймворки и коммьюнити, участвующие в развитии этих решений.
На текущий момент можно выделить три наиболее значимых решения для разработки server side swift:
В части документации и поддержки, мне более нравится Vapor, но это дело вкуса. Кому то будут близки другие решения. Так или иначе, во многих моментах они похожи.
Естественно, что далее на протяжении всего цикла статей в своих примерах я буду использовать Vapor. На его основе мы реализуем сервис регистрации/авторизации пользователя, отправку и подтверждение email, возможность сброса и изменения пароля.
Стоит ли делать реализацию без практической пользы?
Скорей всего, нет! Поэтому мы сделаем максимально взрослый сервис, который можно брать и использовать для организации логики хранения данных пользователя на своем сервере.
Если решение взрослое, то оно влечет применение обдуманных решений. Мы должны упростить масштабирование, реализовать валидацию данных и предусмотреть хранение сессии пользователя, чтобы не заставлять его каждый раз вводить свой логин и пароль.
Что нам для этого потребуется?
Честно говоря, я в свое время скептически относился к докеру, но следовало более внимательно рассмотреть эту технологию. Цель статьи не в объяснении его работы и обучению работы с ним (подозреваю, что мне самому предстоит еще узнать много интересных возможностей докера). Но те, кто не знает, что это такое, и как с ним работать, могут самостоятельно начать знакомство с Docker по официальной ссылке: www.docker.com
Забегая вперед, оставлю еще полезную ссылку на приложение Kitematic, которое призвано упростить работу с контейнерами докера: kitematic.com (must have для тех, кто не любит пользоваться терминалом).
Итак, начнем с установки Docker на mac-компьютер:
Переходим по ссылке hub.docker.com/editions/community/docker-ce-desktop-mac и скачиваем Get Docker Desktop For Mac (Stable)
Открываем полученный образ и далее, установка ничем не отличается от стандартного копирования приложения в каталог программ.
После достаточно запустить приложение и дождаться полной инициализации сервиса.
Если еще нет Docker ID, то его следует создать на hub.docker.com А если есть, то просто авторизоваться в приложении.
Вот и все, подготовка к использованию Docker завершена. Осталось лишь проверить текущую версию и информацию об окружении.
> docker version
> docker info
На этом подготовка к разработке сервиса авторизации завершена. В следующей части мы посмотрим, как можно использовать контейнеры различных сервисов, разберемся с docker-compose для автоматизации сборки нашего окружения и начнем писать код.
P.S.: Небольшой совет из личного опыта. Когда мы разрабатываем сервисы на своей локальной машине, Docker выделяем для своего использования ресурсы по умолчанию. Если мы хотим визуализировать ожидаемое поведение сервиса на удаленном сервере, стоит позаботиться о ресурсах на локальной машине, максимально приближенным к характеристикам сервера. Сделать это можно в настройках приложения Docker Desktop, что мы скачали:
Автор статьи:
Виталий Подольский, преподаватель HackerU
Самые популярные языки программирования бэкенда: для чего они подходят лучше всего и какие компании их используют
Что такое бэкенд, на Хабре рассказывать не нужно, поэтому сразу переходим к сути статьи. В ней рассказывается о наиболее подходящих для бэкенда языках программирования. Кроме того, автор рассказывает о задачах, для решения которых эти языки идеально подходят и компаниях, которые используют их у себя.
Сложно сосчитать количество статей на Хабре, которые имеют отношение к этому языку. Это один из самых популярных языков программирования, который используется более 20 лет.
Универсальным он является благодаря виртуальной машине Java (Java Virtual Machine, JVM). Она позволяет коду на Java одинаково работать на всех совместимых платформах. JVM — своеобразная прослойка, в которой Java-программа преобразуется в код, который может выполняться на любой машине.
Несмотря на то, что Java чрезвычайно популярна среди разработчиков ПО, она сложнее для новичка, чем, скажем, Python. Тем не менее, у Java огромное сообщество, которое даст ответ практически на любой вопрос новичка или профессионала.
Что вы можете делать на Java
На PHP работает около 78.2% всех веб-сайтов. Язык впервые был представлен в 1995 году, когда для создания динамических сайтов существовало не так много возможностей.
Поскольку это динамически типизированный язык, для одной проблемы можно найти сразу несколько решений. Правда, это одновременно означает и то, что один и тот же участок когда может вести себя по-разному в зависимости от конкретной ситуации, что делает программы на PHP сложно масштабируемыми и в некоторых случаях медленными.
79.1% сайтов, о бэкенде которых известно, используют PHP
Компании, которые используют PHP
А сколько получает PHP-разработчик?
.NET (C#, VB)
Основа языка — архитектурный шаблон MVC (Model-View-Controller). В этой схеме контроллер принимает запросы пользователя и взаимодействует с моделью для обработки данных. Потом результат уже передается в представление, отображаясь в виде интерфейса веб-страницы.
C# — высокоуровневый язык программирования, на котором можно писать софт, независимый от архитектуры процессора конкретного компьютера.
C# популярен среди разработчиков благодаря некоторым преимуществам С++. При этом на нем проще писать код, избегая ошибок, которые характерны для того же С++.
Это язык программирования, который использует графический пользовательский интерфейс для работы с кодом. Это простой язык для начинающих благодаря несложному синтаксису. В целом, чаще всего он используется для прототипирования.
Недостаток VB — большой объем памяти, который необходим для установки и запуска инструментов разработки.
Ruby on Rails — веб-фреймворк на языке программирования Ruby. У него есть целый набор готовых инструментов, которые дают возможность быстро выполнять базовые задачи.
Это лаконичный язык, который не требует много года для бэкенда. Так что разработчики могут быстро создавать и запускать приложения. Также он идеален для прототипирования — примерно так же, как и Python. В начале 2000-х популярность Ruby выросла, но затем снизилась.
Достоинство Ruby в том, что это открытый язык, так что он может быть модифицирован и дополнен.
Python
За последние несколько лет он стал чрезвычайно популярным языком программирования. Язык универсален и используется как для веб-разработки, так и для создания настольных приложений. В интернете есть огромное количество различной информации об этом язык, так что он неплохо подходит для начинающих.
Более того, синтаксис языка простой и понятный, по сравнению с другими бэкенд-языками. Те, кто программирует на Питоне, говорит о коде, как об «элегантном», «читаемом» и «красивом».
Что можно делать на Python
JavaScript
Этот язык можно использовать как для фронтенда, так и для бэкенда. Это отличный язык для новичков. В нем относительно простые настройки, а код можно писать прямо в браузере.
Правда, именно из-за гибкости языка скрипты, написанные на нем, порой работают очень медленно. Кроме того, их сложно как поддерживать, так и масштабировать, как и в случае с другими динамически типизированными языками.
При этом сообщество у языка просто огромное, в Сети большое количество материалов для изучения.
Что можно делать на JavaScript
Языки, на которых пишут разработчики, принявшие участие в опросе Stack Overflow
Комментарий эксперта
Даниил Пилипенко, директор центра подбора IT-специалистов SymbioWay и евангелист бэкенд-направления онлайн-университета Skillbox, дополнил перевод экспертным мнением о востребованности самой специальности “бэкенд-разработчик”.
Спрос на разработчиков последние 20 лет продолжает постоянно расти: каждый год количество вакансий разработчиков увеличивается примерно на 15%. При этом количество самих программистов растет не более, чем на 5% ежегодно. Это приводит к постоянному росту дефицита и, соответственно, зарплат этих специалистов.
Найти хороших и сильных разработчиков становится всё сложнее. Если вы решили создать какой-то проект, лучше выбирать наиболее популярные в настоящее время технологии и языки программирования.
Часто встречаю проекты, на которых в качестве основных технологий выбирают что-нибудь очень редкое вроде Go, Erlang или Flutter, и потом месяцами не могут найти разработчиков.
Как уже было сказано в статье, самые распространённые сейчас языки для backend-разработки — это Java (для крупных решений), PHP (для веб-сайтов) и Python (для небольших веб-решений и научных задач). В случае выбора этих технологий вы сможете относительно быстро находить сильных специалистов, расширять команду и заменять тех, кто выгорел или ушёл. Благодаря этому ваш проект сможет не только появиться на свет, но и вырасти.
Пишем backend для мобильного приложения за несколько минут
Здравствуйте! Моя основная область деятельности — разработка мобильных приложений (iOS, Android). И большая часть приложений, использует взаимодействие с другими пользователями, хранение данных и другие задачи требующие наличие единого сервера. Поэтому для большей части приложений приходится писать свой велосипедbackend. А так как я, в основном являюсь мобильным разработчиком, то написание этого сервиса всегда становится небольшой проблемой — приходится задействовать веб-разработчика или искать подходящий BaaS сервис, даже если надо написать всего пару запросов.
Поэтому было принято решение, попробовать найти инструмент, позволяющий в короткие сроки написать небольшой веб-сервис, который можно было бы использовать в мобильном приложении.
За исходные данные были приняты: знание что такое HTTP, REST, JSON и начальный уровень разработки на Python (Django).
И вот на днях, на глаза попался небольшой проект, на котором можно было провести полевые испытания. Суть проекта — приложение для одного мероприятия. Нужно отображать спикеров и их доклады.
После непродолжительных поисков, за основу были взяты следующие инструменты: Python (как основной язык разработки), Django (как базовая платформа) и фреймворк Tastypie (представленный как фреймворк для создания API веб-сервисов). Итак, приступим.
Создаем шаблон приложения Django:
В настройках файла settings.py прописываем необходимые настройки для базы данных, локализацию, время. Устанавливаем пакет tastypie:
Обратите внимание, что требуется Python2.6+ и Django 1.5+. Из-за незнания этого факта пришлось потратить немного больше времени, т.к. фреймворк отказывался работать. Кроме того, нужно установить аналогичным образом пакет python-mimeparse.
Далее, в файле settings.py, прописываем:
или добавляем уже в существующий список приложение ‘tastypie’.
Теперь пропишем модели нашей предметной области:
Мы написали модель докладчика (Speaker) и модель выступления (Event). У каждого выступления обязательно есть докладчик. Теперь, сделаем так, чтобы мы могли полноценно работать с нашими моделями как с ресурсами через REST протокол.
Создаем в нашем приложении пакет api и файлом resources.py (или можно его создать в основном пакете).
В этом файле мы создали классы, так называемых ресурсов, основных объектов в нашем REST сервисе. Это как раз те ресурсы, к которым мы будем обращаться. Каждый класс содержит ссылку на ту модель, которую он представляет. Поле queryset возвращает нам набор объектов получаемых из базы при обращении к даному ресурсу. Поле resource_name необязательно, и позволяет нам указать дополнительно наименование ресурса, по которому он будет доступен нам.
Еще один момент, в классе EventResources мы указали отдельное поле speaker, которое указывает что ресурс события ссылается на ресурс спикера.
Теперь осталось только прописать в файле urls.py обращения к нашему сервису. Это делает очень просто.
Теперь запускаем наш проект
Теперь, если сервер успешно запустился, открыв в браузере страницу по адресу http://localhost:8000/api/entry/?format=json, увидим там что фреймворк видит все наши ресурсы и отобразил нам схему нашего сервиса:
Параметр format принудительно указывает в каком формате мы хотим получить данные, но вместо него можно в запросе указать заголовок Content-type: application/json. Кроме JSON поддерживаются xml, yaml, bplist.
По адресу schema можно посмотреть описание структуры модели (поля, типы и описание), а по адресу list_endpoint можно уже получить наши ресурсы, которые мы предварительно записали в базу.
Теперь, открыв адрес http://localhost:8000/api/v1/events/?format=json мы увидим там что-то вроде этого:
Как видим — ничего сложного. В разделе meta выводится основная информация о ресурсе: количество записей, размер выдачи и тд. Одновременно мы можем обратиться к конкретному событию, обратившись к ресурсу по его id — http://localhost:8000/api/v1/events/1/
Можем создать запись выполнив POST запрос и передав в него объект в JSON формате, обновить запись PUT запросом и удалить с помощью DELETE.
Так же, в tastypie у класса ModelResource есть большой набор переопределяемых полей и методов, с помощью которых мы можем полностью изменить структуру выдаваемых данных. Например, мы хотим вместо ссылки на спикера, сразу получать его имя, чтобы не делать лишний запрос. В классе EventResource переопределяем метод dehydrate:
В нем, мы находим спикера в базе и подставляем его в объект bundle, который представляет из себя словарь который отдается ресурсом. Теперь, ответ на запрос будет выглядеть так (напишу только основную часть):
Как написать максимально хреновый бэкенд для мобильного приложения
Известно, что практически ни одно мобильное приложение не обходится без бэкенда.
Если вы мобильный разработчик, то наверняка сталкивались с такими бородатыми дядями, которые меланхолично тянут логику на перле и вечно что-то пишут в консоли. Или может это был сутулый анимешник с длинными волосами, всосавший php с молоком матери.
Так или иначе, большинство из них ни разу не сталкивалось с мобильной разработкой, а кое-кто считает себя при этом гуру.
Специально для таких случаев, я подготовил список вредных советов о том как угробить бэкенд вашего приложения.
Приятного чтения.
Итак, если вы серверный разработчик:
Когда показывал эту статью коллегам, то многие бэкенд разработчики тоже решили поделиться парой наболевших моментов:
(Может быть, им просто одиноко и не с кем поговорить?)
Полезные рекомендации
Вместе посмеяться над знакомыми ситуациями — это здорово, но кроме этого хотелось бы поделиться еще действенными практиками, которые мы используем у себя. Даже когда приходится работать с внешними мобильными разработчиками, они всегда благодарят нас за исключительно удобное API и профессионализм.
Все дальнейшие советы относятся к бэкенду, но если вы мобильный разработчик, то вам тоже будет интересно и полезно это прочитать. Ведь в первую очередь именно вы заинтересованы в изменениях.
Документация
Это интерфейс для мобильного разработчика. Она должна быть не просто информативна, но еще легко читаться и быть приятной глазу. Звучит странно, но чем легче воспринимается документ, тем быстрее и проще с ним работать, и тем меньше возникает к вам вопросов в процессе.
Самый простой и удобный вариант — это использовать Swagger. Хоть его изначальный внешний вид и оставляет желать лучшего:
Но его можно без проблем облагородить с помощью форматтера:
Получается симпатично и удобно. В качестве альтернатив можно использовать Apiary, но придется разделять код и документацию, что нежелательно, либо заморачиваться с рендерингом.
Единообразие
В мобильной разработке есть сложность — многие решения и фреймворки крайне неповоротливы. Нельзя просто взять и поменять формат для какого-то одного конкретного запроса, либо это предельно сложно. Как и нельзя изменить название определенного поля только для определенного случая: бедный девелопер будет орать в голосину, пытаясь воткнуть под это костыль.
Все должно быть целостно: везде одинаковые названия, один формат взаимодействия (предпочтительно JSON), и тп.
Особенно хорошо, если названия параметров в запросе и ответе идеально совпадают с полями соответствующих классов в мобильном приложении. Звучит странно, но это настолько упрощает жизнь разработчикам, что они будут вам за это шоколадки таскать из магазина.
В некоторых местах упрощение доходит до абсурда: например, сохранение в Realm (мобильная база данных) может быть произведено практически сразу из json. Если будет интересно, то отдельно расскажу о том, как мы избавлялись от middleware в мобильном приложении.
Пример кода по сохранению любых пришедших объектов на iOS:
Один generic метод на любую запись в базу с сервера. Классно, правда?
Тоже самое касается и изображений. Лучше всего, когда на картинку сразу приходит ссылка, которую не нужно ‘доделывать’. И по тому же правилу — название ссылки должно быть везде одинаковым.
У нас был случай, когда нужно было искать изображения в гугле для определенных информационных блоков в мобильном приложении. В итоге мы просто сделали псевдо-ссылку на картинку, к которой приложение обращается, а внутри сервак ищет подходящее изображение в гугле и делает на нее редирект. А для приложения это выглядит как самая обыкновенная пикча, которая просто немного дольше соображает.
Достаточность
Когда работаешь над сервером, то привычно, что все находится в едином scope запроса, где достаточно просто открыть транзакцию на запись и в нее последовательно протолкнуть данные. Все изолированно, предсказуемо и линейно.
В мобильном приложении такого нет. Все крутится асинхронно, а если требуется соблюсти целостность данных из разных запросов, то это выливается в сложнейшие манипуляции с многопоточностью, злющими критическими секциями и распределением приоритетов, чтобы не было и намека на тормоза. Не зря вопрос про синхронизацию потоков в собеседовании на мобильного разработчика задают одним из первых.
Теперь понимаете, почему мобильные девелоперы стараются, чтобы все приходило в едином запросе? От этого зависит, уйдут они сегодня домой или нет)
И конечно, если какие-то данные нужно загрузить асинхронно, то не надо их пихать в общую кучу, это надо понимать.
В конце концов, не поленитесь открыть дизайн приложения и посмотреть из чего состоит экран для которого вы делаете API. Посоветуйтесь с вашими мобильными коллегами, определите как лучше вам отдавать им данные и какие последующие запросы будут от них зависеть. Может быть, в данном конкретном запросе нужно выдать чуть больше информации, чем кажется достаточным. Но зато это сделает последующую работу удобнее и приятнее на клиенте. Помогая в таких мелочах, вы надолго запомнитесь. И потом будут вспоминать с теплотой всю их профессиональную жизнь.
В этот же пункт хочется отнести отладочную информацию. Если вы сделали запрос для получения списка комментариев, то озаботьтесь, чтобы эти комментарии там были. Вам накопипастить однотипных данных — дело одной минуты, а для напарника из мобильного отдела — это целый выдох облегчения.
Стабильность
Просто архиважный пункт на который хочется отдельно обратить внимание. Всегда проверяйте свое API, а еще лучше — пусть тесты делают это за вас. Каждый баг на бэкенде равен десяти на клиенте. Ведь между сервером и пользователем находится множество уровней абстракций, которые надо исключить перед тем, как винить сервер.
Каждый баг тратит время пользователя, тестировщика, мобильного разработчика и только потом — вас. На вас возложена наибольшая ответственность, и ваши ошибки обходятся компании дороже всего.
В качестве бонуса хочется добавить, что здорово, когда есть pretty print, хотя бы на время разработки. Бывает, что надо разобраться с тем, что пришло от сервера, не заглядывая в документацию.
А что приятнее читать, такое:
Разница, мне кажется, на лицо.
Главное, не забудьте отключить Pretty Print на боевом сервере, поскольку ресурсов он жрет как не в себя.
Заключение
Хочется всем просто сказать, что правило на самом деле одно и довольно простое — не заставляйте коллег скрежетать зубами от вашей работы.
В следующий раз планирую рассказать о том, как мы переезжали на Go и избавились от огромного куска бизнес логики на клиенте, сократив бинарник приложения больше, чем на треть.