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

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

Мобильные приложения можно разделить на две базовых группы.

Игровые приложения

К первой группе можно отнести игровые приложения из-за их специфики: требований к производительности, возможностям интерактивной анимации и используемых технологий. Основное отличие игровых приложений заключается в используемых сетевых протоколах. Например, когда приложение имеет интерактивный режим (например, режим боя в реальном времени), то может использоваться протокол на основе сетевого стека UDP. В остальных случаях для связи с серверной частью используются протоколы поверх стека TCP/IP.

Помимо этого можно выделить еще одно отличие игровых приложений – это используемый стек технологий для реализации клиентской части. В большинстве случаев игровые приложения написаны на языках отличных от тех, которые используются для создания обычных мобильных программ. Здесь можно выделить использование движков Unity (C#), Unreal Engine и менее распространенных, таких как Cocos2dx (С++). Конечно, для некоторых игровых жанров используются и нативные языки платформы. Стоит вспомнить известную всем известную 2048, но это скорее исключение из правил.

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

Обычные приложения

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

Нативные

Классическим вариантом является использование нативных языков и их вариаций, таких как Java, Kotlin, Objective-C и Swift. К преимуществам использования нативных языков можно отнести очень высокую скорость исполнения и относительно малый размер бинарного файла, но здесь стоит учитывать и размер ассеттов (изображений, шрифтов и т.д.).

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

Flutter

Решить проблему позволяет очень популярный тренд – использование фреймворка Flutter. Он сокращает затраты на разработку благодаря единой кодовой базе для Android и iOS, а также имеет более широкие возможности интерактивной анимации. Помимо этого при помощи паттерна проектирования Block можно использовать код и для веб-реализации. Flutter использует язык Dart и построен поверх графической библиотеки Skia с обширной кодовой базой на C++.

Рендеринг в Skia производится средствами GPU, что делает приложение более отзывчивым. Помимо программной анимации Flutter имеет возможность проигрывать анимации Lottie, которые можно создавать в Adobe After Effects.

К преимуществам использования Flutter для разработки мобильного приложения можно отнести достаточно низкие затраты, высокую производительность приложения и возможности анимации. Я не могу найти недостатков, кроме незначительного увеличения размера приложения за счет Flutter runtime.

React-Native

Еще один распространенный вариант – разработка на основе веб-технологий. Здесь лидирует React Native. Признаюсь честно, я не большой поклонник React, но постараюсь не предвзято оценить его использование. Неоспоримым преимуществом является доступность владеющих этой технологией программистов и возможность задействовать штатных веб-разработчиков для создания мобильного приложения. В основном поэтому на React Native делают в основном MVP (minimum viable product).

Если у вас есть разработчики полного цикла (full-stack), то и для серверной части вы скорее всего предпочтете использовать Node.js. React Native также неплохо поддерживает анимацию, включая анимации Lottie. К сожалению, таким же неоспоримым недостатком является очень скудная производительность приложения. Исходя из своего опыта, переписывать продукты с другим технологическим стеком приходится именно по этой причине.

PWA

Отдельной категорией можно считать PWA (progressive web app). Они не являются мобильными программами в привычном понимании. Это прогрессивные веб-приложения, работающие в интегрированном браузере. PWA создаются с использованием таких языков как JavaScript, TypeScript и Dart. Это достаточно удачный выбор для создания MVP, а возможно и финального приложения.

Сетевой стек мобильного приложения

Чтобы оценить требования к сети, предъявляемые мобильным приложением рассмотрим интернет-магазин в качестве примера.

Базовые состояния приложения:

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

Для каждого из этих состояний приложению достаточно совершить один запрос к серверной части, получить ответ и отобразить данные. Собственно говоря, это стандартный Rest API поверх HTTPS. Теперь попробуем добавить в наше приложение возможность общения с консультантом магазина:

• Отправка сообщения серверу.
• Получение сообщения от сервера.

Отправка может быть осуществлена с помощью привычного нам Rest API, но какие варианты есть для получения сообщения от сервера?

Конечно, мы можем использовать Push Notification и нам в любом случае придется применить эту технологию для получения сообщений в режиме offline. Однако, использование Push Notification для сообщений в online-режиме является нецелесообразным из-за задержки доставки.

Ping-pong

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

Longpoll

Старый добрый longpoll появился до HTML5: он отличается от ping-pong тем, что закрытие соединения не инициируется со стороны клиента или сервера. Оно остается открытым, и в него можно отправлять данные до тех пор, пока не выйдет время жизни соединения (TTL). Настройки TTL устанавливаются на стороне сервера. После закрытия соединения клиентское приложение может восстановить его немедленно или через определенный промежуток времени.

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

WebSocket

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

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

SSE

Основным отличием протокола HTTP/2 от HTTP являлось снижение задержки за счет обеспечения полного мультиплексирования запросов и ответов, минимизации накладных расходов протокола посредством сжатия полей заголовков HTTP и добавления поддержки приоритизации запросов и отправки на сервер. Этот протокол обладал и еще одним нововведением – поддержкой субпротокола Server Socket Events.

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

В отличие от WebSocket, он поддерживает обмен данными только в текстовом формате. Такое ограничение возникло из целей протокола, так как большая часть потребностей была связанна с доставкой текстовых уведомлений по подобию Push Notification. Это позволило упростить протокол обмена данными, для остальных же задач вы можете задействовать WebSocket. При использовании SSE для поддержания обратной связи мы по-прежнему можем и будем работать с привычным нам Rest API для отправки запросов на сервер.

На мой взгляд, это самая оптимальная схема взаимодействия между клиентским и серверным приложением на данный момент, которая к том же работает поверх HTTP/2. Server Socket Events обеспечивает оптимальное соотношение между требованиями к ресурсам и производительностью, предоставляя возможности асимметричной двусторонней связи.

Итоги

Возможно ли задействовать разработчиков клиентской части для создания бэкенда?

По очевидным причинам лидирующие позиции здесь занимают веб-разработчики и Node.js. Конечно, серверную часть делают и Flutter-разработчики. Dart позволяет писать сетевые серверные приложения, и, возможно, они удивят вас своей производительностью по сравнению с Node.js.

Скорее всего Flutter-разработчики будут не готовы к этим переменам, ввиду невостребованности такого использования языка Dart. Не хотелось бы рассматривать реализацию серверной части на Java по той же причине, а также из-за требовательности к ресурсам сервера и производительности системы ввода-вывода.

С точки зрения затрат и при отсутствии специализированных разработчиков в штате, идеальным решением было бы создание MVP на React-Native и серверной части на основе Node.js. Однако при отсутствии в штате веб-разработчиков лучшим решением, возможно, было бы использование Flutter в качестве основы.

Оценивая варианты сетевого взаимодействия мы, естественно, ориентировались на привычный для веб-разработчика стек протоколов.

Стоит также упомянуть протокол QUIC, построенный поверх UDP, который несет еще большие выгоды по сравнению с рассмотренными выше схемами сетевого взаимодействия. QUIC – новый транспортный протокол связи, который отличается уменьшенным временем задержки, большей надежностью и безопасностью – он взят за основу будущего стандарта HTTP/3. Учитывая, что QUIC работает поверх UDP, возможно его применение даже в интерактивных игровых приложениях. Пока использование QUIC для реальных проектов остается вопросом будущего, поскольку он принят в качестве официального стандарта только в мае 2021 года.

Legacy-природа таких схем как ping-pong и longpoll делает их не столь привлекательными по сравнению с другими вариантами. Помимо этого не нужно забывать о неэффективности использования ресурсов протоколом WebSocket. Очевидным лидером для реализации сетевого взаимодействия на сегодняшний день является Server Socket Events в связке с REST API. В будущем же стоит присмотреться к QUIC.

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

Selectel предлагает серверы, оснащенные 4-768 ГБ ОЗУ, 2-72 ядрами ЦП, а также с возможностью подключить графический ускоритель и выбрать в качестве сервера даже Raspberry Pi 4 (4/64 ГБ) и Mac Mini для iOS-разработчиков.

Интересно, посмотреть тарифы Selectel