бэкэнд для мобильного приложения
Как организовать бэкенд мобильного приложения?
Что мы делаем? Сервис регистрации и авторизации пользователя для мобильного приложения
В пет-проектах каждого мобильного разработчика рано или поздно наступает момент, когда требуется быстро и без лишней головной боли создать сервер для своего приложения. Не важно, какую функцию должен выполнять сервер: будь то хранение данных или регистрация/авторизация пользователей.
Как правило, вначале все идут (ну или большинство) по пути наименьшего сопротивления. Мы ищем готовое решение и смотрим, как быстро его можно приспособить для наших нужд.
На данном этапе первое, что получается «нагуглить» — это сервисы 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
Как стать фулстек-разработчиком мобильных приложений
Авторизуйтесь
Как стать фулстек-разработчиком мобильных приложений
фулстек-разработчик мобильных приложений в IT-компании Neti
Меня зовут Ленар Деллерт, я фулстек-разработчик мобильных приложений в IT-компании Neti. Разрабатывать и для веба, и для «мобилок» научился сам, какого-то специального «программистского» образования у меня нет. В статье объясню, какие специалисты требуются в мобильной разработке, расскажу, как освоил программирование с нуля, и поделюсь ресурсами, на которых можно учиться.
Бэкенд, фронтенд, фулстек: кто есть кто в мобильной разработке
В основном мобильные приложения состоят из фронтенда и бэкенда: фронтенд — интерфейс, с которым взаимодействует пользователь, а бэкенд — серверная часть, на которой хранится и обрабатывается информация. Фронтенд и бэкенд обмениваются данными через API.
Сделать бэк сложнее, чем фронт, потому что чаще всего именно на бэкенде закладывается бизнес-логика программы. Если бэкенд и API реализованы плохо, приложение будет тормозить, вылетать и раздражать пользователей. Серверную часть и API делают бэкенд-разработчики. В нашей компании бэкендеры кодят на PHP на фреймворках Laravel и Yii2.
Бывают простые приложения без бэка, но они «зациклены» на самих себе: через них нельзя, например, оплатить заказ в корзине, попереписываться с менеджером в чате, забронировать столик.
Теперь поговорим о том, кто реализует фронтенд. Если бы речь шла о разработке сайтов, я бы написал, что для создания фронта нужен фронтенд-разработчик. Но в мобильной разработке все немного запутаннее: здесь фронтендом занимаются разработчики кроссплатформенных решений и разработчики нативных приложений.
При нативном подходе для операционных систем Android и iOS делают два отдельных приложения. Для этого требуются два специалиста: android-разработчик, который пишет на Java или Kotlin, и iOS-разработчик, который пишет на Objective-C или Swift.
При кроссплатформенной разработке нужен всего один программист. Он пишет код на фреймворках React Native, Flutter или Xamarin, а потом компилятор адаптирует этот код под Android и iOS. React Native разработчик должен знать JavaScript, Flutter-разработчик — язык Dart, чтобы писать на Xamarin, нужно владеть С#.
Еще есть фулстек-разработчики — это специалисты два в одном, которые могут сделать и бэкенд, и фронтенд. Я фулстек-разработчик мобильных приложений: бэкенд реализую на Yii2, фронтенд — на React Native. Нативные приложения не совсем мой профиль: я пробовал писать под iOS и Android в рамках коммерческой разработки, но считаю, что у меня недостаточно опыта, чтобы давать какие-то советы.
Теория
Если человек задумывается о карьере в IT, в первую очередь он должен понять, интересна ли ему эта сфера. Готов ли он целый день сидеть и писать код? Не захочет ли все бросить, если над задачей придется биться несколько часов? Идти в программирование из-за хороших зарплат не стоит, потому что деньги — недостаточная мотивация. Многие забывают, что зарабатывать люди начинают после того, как потратят несколько лет на обучение и приобретение опыта.
Я считаю, что человеку должно быть по-настоящему интересно то, что он делает. В этом секрет. Когда у меня появился высокоскоростной интернет, мне стало интересно, как работают сайты. Я полазил по разным ресурсам, форумам и узнал об HTML и CSS. Нашел по ним уроки, познакомился с базовыми понятиями и стал делал html-странички. Потом захотел придать им интерактивности, понял, что для этого нужен язык JavaScript, и начал изучать его.
Сайты, на которых я изучал HTML, CSS, JavaScript:
Дальше я заинтересовался, как сделать полноценный сайт. Только на одном фронтенде приложение держаться не может: для более сложных действий, например, для авторизации пользователя, нужен бэкенд. Так я вышел на язык PHP и объектно-ориентированное программирование.
Ресурсы для изучения PHP:
Я увлекся программированием, когда учился в консерватории. Времени на хобби было мало: иногда занятия в вузе начинались в 7 утра и заканчивались в 7 вечера плюс я работал педагогом в музыкальной школе. Но разрабатывать сайты нравилось мне все больше. На втором курсе я понял, что хочу стать программистом, а не музыкантом, и бросил консерваторию. Но музыкой занимаюсь до сих пор для себя.
Моя страсть узнавать новое привела меня в мобильную разработку. Когда я уже работал PHP-программистом, мне было скучно использовать одни и те же инструменты, и я попросил тимлида, который писал под iOS и Android, научить меня разрабатывать под одну из этих ОС. Он показал, как делать приложения под Android. Это меня увлекло. Сначала я писал под Android, потом захотелось попробовать кроссплатформенные решения и я разобрался во фреймворке Xamarin.
В 2019 году мне предложили сделать мобильное приложение на React Native для логистической компании, и я согласился, хотя раньше не писал на этом фреймворке. Было интересно, как он работает. Чтобы освоить React Native, я читал документацию, лазил по GitHub и форумам. Как всегда, спасал сервис Stack Overflow: если не хватало информации, я находил там ответы на свои вопросы. Если я не знал, как решить задачу, я гуглил. Умение гуглить очень важно для любого разработчика. Кстати, лучше формулировать запросы на английском языке — так больше шансов найти ответ.
Практика
Даже вызубрив документацию от и до, технологию не освоишь. Чтобы закрепить знания, необходимо практиковаться.
Изучая новый язык или фреймворк, я часто пишу что-то для себя. К примеру, чтобы понять, как работает Zend Framework, я разбирал его компоненты. Брал Query Builder, который используется для построения SQL-запросов, копался в нем и пытался написать свой «велосипед». Затем разбирался в следующем компоненте.
Чтобы освоить Swift и среду разработки Xcode, я написал для часов Apple Watch приложение, которое в реальном времени показывает погоду. Не скажу, что после этого стал крутым iOS-разработчиком, но теперь проверяя код для iOS других программистов, могу понять, что написано, и посоветовать, как сделать лучше.
Алгоритм для тех, кто хочет стать разработчиком, такой:
Дальше расскажу, какие технологии должны знать начинающие React Native и бэкенд-разработчики, чтобы найти работу.
Что должен знать начинающий React Native разработчик
Чтобы устроиться младшим React Native разработчиком, нужно освоить на базовом уровне следующие технологии:
Что должен знать начинающий бэкенд-разработчик мобильных приложений
Вот что должен знать джун-бэкендер, чтобы получить работу:
У нас на собеседовании еще могут поспрашивать по архитектурным паттернам. Это сложнее, поэтому знать необязательно, но будет плюсом.
Soft Skills
Стоит добавить, что кроме hard skills джуниор-программисту пригодятся такие soft skills:
Нет универсального рецепта, по которому каждый человек освоил бы программирование. Я поделился своим видением. Возможно, кому-то больше понравится проходить курсы. Хорошие курсы помогут быстрее составить правильное представление о базовых вещах, чем формировать его самому. Но разбираться, как лучше решить практическую задачу заказчика, исходя из контекста ситуации, все равно придется самостоятельно, параллельно восполняя пробелы по документации, сайтам и форумам. Это и называется опыт. В любом случае главное — не бояться и делать. Если с первого раза не получилось — переделывать. Тогда точно получится.
Самые популярные языки программирования бэкенда: для чего они подходят лучше всего и какие компании их используют
Что такое бэкенд, на Хабре рассказывать не нужно, поэтому сразу переходим к сути статьи. В ней рассказывается о наиболее подходящих для бэкенда языках программирования. Кроме того, автор рассказывает о задачах, для решения которых эти языки идеально подходят и компаниях, которые используют их у себя.
Сложно сосчитать количество статей на Хабре, которые имеют отношение к этому языку. Это один из самых популярных языков программирования, который используется более 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 (для небольших веб-решений и научных задач). В случае выбора этих технологий вы сможете относительно быстро находить сильных специалистов, расширять команду и заменять тех, кто выгорел или ушёл. Благодаря этому ваш проект сможет не только появиться на свет, но и вырасти.
Как написать максимально хреновый бэкенд для мобильного приложения
Известно, что практически ни одно мобильное приложение не обходится без бэкенда.
Если вы мобильный разработчик, то наверняка сталкивались с такими бородатыми дядями, которые меланхолично тянут логику на перле и вечно что-то пишут в консоли. Или может это был сутулый анимешник с длинными волосами, всосавший php с молоком матери.
Так или иначе, большинство из них ни разу не сталкивалось с мобильной разработкой, а кое-кто считает себя при этом гуру.
Специально для таких случаев, я подготовил список вредных советов о том как угробить бэкенд вашего приложения.
Приятного чтения.
Итак, если вы серверный разработчик:
Когда показывал эту статью коллегам, то многие бэкенд разработчики тоже решили поделиться парой наболевших моментов:
(Может быть, им просто одиноко и не с кем поговорить?)
Полезные рекомендации
Вместе посмеяться над знакомыми ситуациями — это здорово, но кроме этого хотелось бы поделиться еще действенными практиками, которые мы используем у себя. Даже когда приходится работать с внешними мобильными разработчиками, они всегда благодарят нас за исключительно удобное API и профессионализм.
Все дальнейшие советы относятся к бэкенду, но если вы мобильный разработчик, то вам тоже будет интересно и полезно это прочитать. Ведь в первую очередь именно вы заинтересованы в изменениях.
Документация
Это интерфейс для мобильного разработчика. Она должна быть не просто информативна, но еще легко читаться и быть приятной глазу. Звучит странно, но чем легче воспринимается документ, тем быстрее и проще с ним работать, и тем меньше возникает к вам вопросов в процессе.
Самый простой и удобный вариант — это использовать Swagger. Хоть его изначальный внешний вид и оставляет желать лучшего:
Но его можно без проблем облагородить с помощью форматтера:
Получается симпатично и удобно. В качестве альтернатив можно использовать Apiary, но придется разделять код и документацию, что нежелательно, либо заморачиваться с рендерингом.
Единообразие
В мобильной разработке есть сложность — многие решения и фреймворки крайне неповоротливы. Нельзя просто взять и поменять формат для какого-то одного конкретного запроса, либо это предельно сложно. Как и нельзя изменить название определенного поля только для определенного случая: бедный девелопер будет орать в голосину, пытаясь воткнуть под это костыль.
Все должно быть целостно: везде одинаковые названия, один формат взаимодействия (предпочтительно JSON), и тп.
Особенно хорошо, если названия параметров в запросе и ответе идеально совпадают с полями соответствующих классов в мобильном приложении. Звучит странно, но это настолько упрощает жизнь разработчикам, что они будут вам за это шоколадки таскать из магазина.
В некоторых местах упрощение доходит до абсурда: например, сохранение в Realm (мобильная база данных) может быть произведено практически сразу из json. Если будет интересно, то отдельно расскажу о том, как мы избавлялись от middleware в мобильном приложении.
Пример кода по сохранению любых пришедших объектов на iOS:
Один generic метод на любую запись в базу с сервера. Классно, правда?
Тоже самое касается и изображений. Лучше всего, когда на картинку сразу приходит ссылка, которую не нужно ‘доделывать’. И по тому же правилу — название ссылки должно быть везде одинаковым.
У нас был случай, когда нужно было искать изображения в гугле для определенных информационных блоков в мобильном приложении. В итоге мы просто сделали псевдо-ссылку на картинку, к которой приложение обращается, а внутри сервак ищет подходящее изображение в гугле и делает на нее редирект. А для приложения это выглядит как самая обыкновенная пикча, которая просто немного дольше соображает.
Достаточность
Когда работаешь над сервером, то привычно, что все находится в едином scope запроса, где достаточно просто открыть транзакцию на запись и в нее последовательно протолкнуть данные. Все изолированно, предсказуемо и линейно.
В мобильном приложении такого нет. Все крутится асинхронно, а если требуется соблюсти целостность данных из разных запросов, то это выливается в сложнейшие манипуляции с многопоточностью, злющими критическими секциями и распределением приоритетов, чтобы не было и намека на тормоза. Не зря вопрос про синхронизацию потоков в собеседовании на мобильного разработчика задают одним из первых.
Теперь понимаете, почему мобильные девелоперы стараются, чтобы все приходило в едином запросе? От этого зависит, уйдут они сегодня домой или нет)
И конечно, если какие-то данные нужно загрузить асинхронно, то не надо их пихать в общую кучу, это надо понимать.
В конце концов, не поленитесь открыть дизайн приложения и посмотреть из чего состоит экран для которого вы делаете API. Посоветуйтесь с вашими мобильными коллегами, определите как лучше вам отдавать им данные и какие последующие запросы будут от них зависеть. Может быть, в данном конкретном запросе нужно выдать чуть больше информации, чем кажется достаточным. Но зато это сделает последующую работу удобнее и приятнее на клиенте. Помогая в таких мелочах, вы надолго запомнитесь. И потом будут вспоминать с теплотой всю их профессиональную жизнь.
В этот же пункт хочется отнести отладочную информацию. Если вы сделали запрос для получения списка комментариев, то озаботьтесь, чтобы эти комментарии там были. Вам накопипастить однотипных данных — дело одной минуты, а для напарника из мобильного отдела — это целый выдох облегчения.
Стабильность
Просто архиважный пункт на который хочется отдельно обратить внимание. Всегда проверяйте свое API, а еще лучше — пусть тесты делают это за вас. Каждый баг на бэкенде равен десяти на клиенте. Ведь между сервером и пользователем находится множество уровней абстракций, которые надо исключить перед тем, как винить сервер.
Каждый баг тратит время пользователя, тестировщика, мобильного разработчика и только потом — вас. На вас возложена наибольшая ответственность, и ваши ошибки обходятся компании дороже всего.
В качестве бонуса хочется добавить, что здорово, когда есть pretty print, хотя бы на время разработки. Бывает, что надо разобраться с тем, что пришло от сервера, не заглядывая в документацию.
А что приятнее читать, такое:
Разница, мне кажется, на лицо.
Главное, не забудьте отключить Pretty Print на боевом сервере, поскольку ресурсов он жрет как не в себя.
Заключение
Хочется всем просто сказать, что правило на самом деле одно и довольно простое — не заставляйте коллег скрежетать зубами от вашей работы.
В следующий раз планирую рассказать о том, как мы переезжали на Go и избавились от огромного куска бизнес логики на клиенте, сократив бинарник приложения больше, чем на треть.