Перейти к основному содержимому

Модельная разработка мобильных приложений React Native и сайтов на React Native Web.

ModelDevs!

Перед тем как мы перейдем к стадиям "Модельной разработки", посмотрим на традиционный метод разработки приложений - «Разработка по фичам» - это метод, при котором ставиться задача с описанием функциональности и с ссылкой на Zepllin и в лучшем случае ссылки на экраны прототипа в Marvel App. Когда программист получает задачу на разработку фичи, то он разделяет ее на три части:

  • Верстает UI
  • Создает экраны с навигацией
  • Реализует логику взаимодействия локального и облачного хранилища базы данных

ModelDevs!

В результате от желаемого мы видим картину, где UI компоненты верстаются прямо на экранах и слой верстки сливается с навигацией и логикой на одном экране, что в свою очередь выходит за границы методологии "Атомарный дизайн (Atomic design)" и его лозунга «Создавайте системы, а не страницы».

ModelDevs!

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

Для того чтобы исключить эту проблему я использую альтернативный способ разработки, он же метод «Модельная разработка». Основное его отличие от метода «Разработка по фичам» в том, что изначально мы ставим задачу в виде типизируемой модели(схемы) TypeScript и GraphQL, что позволяет разработчику использовать типизацию кода не по остаточному принципу, как это обычно бывает, а фундаментально на уровне создания технического задания. И так мы изначально закладываем в задачу типизируемую модель реализации базы данных, что дает нам возможность контролировать точность выполнения задачи на протяжении всего жизненного цикла выполнения задачи из бэклога в done.

ModelDevs!

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

ModelDevs!

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

  • Верстальщик(Junior) - верстка - UI Components
  • Сборщик(Middle) - сборка экранов и логики навигации - Screens
  • Проектировщик(Senior) - разрабатывает техническое задание в виде TypeScript и GraphQL модели - Logic.

ModelDevs!

Самый лучший способ что-то объяснить, показать пример на себе, поэтому покажу, как я проектирую истории для своего мобильного приложения "Игра Лила" с помощью метода «Модельная разработка».

Игра Лила

Сейчас мы создадим историю на декомпозицию экрана ProfileScreen.

ModelDevs!

С этим методом разработка приложения может быть в разы быстрей и называется он «Модельная разработка», потому что любая история декoмпозируется на три задачи, где в одной задаче реализуется TypeScript модель, во второй GraphQL модель, а в третей ее деплой на сервер:

model

Шаг 1 - UI Components - Верстка - TypeScript модель компонента#

ModelDevs!

ModelDevs!

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

Создание мобильного приложения React Native начинается с создания UI Components в Storybook, из которых будет строиться приложение. Это наши строительные блоки, атомы, молекулы, организмы, из которых состоит вся визуальная часть приложения(screens).

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

Благодаря тому, что мы делаем приложение по правилам Storybook наши компоненты легко переносятся на React Native for Web. Из-за чего мы получаем UI-kit не только для мобильной разработки, но также мы можем использовать его и на сайте, получая ускорение процесса разработки в два раза по верстке, так как нам не нужно верстать компоненты для сайта отдельно от мобильной платформы.

"Storybook - это мощный инструмент фронтенда, который позволяет командам проектировать, создавать и организовывать компоненты пользовательского интерфейса (и даже полные экраны!), Не отвлекаясь от бизнес-логики и сантехники."

Brad Frost - автор Atomic Design

В наше время кого не спроси про атомарный дизайн (Atomic design), то следовать под его лозунгом «Создавайте системы, а не страницы» готовы все, но к сожалению на практике разработчики продолжают создавать страницы к которым прикручивают бизнес-логику.

Основные преимущества создания UI Components в Storybook:#

Изоляция#

Реализация компонентов происходит без возни с данными, API или бизнес-логикой, так как UI Components изолированы от слоя навигации с экранами и клиентам приложения.

isolation

Имитация труднодоступных варианты использования#

Рендеринг компонентов в ключевых состояниях под нагрузкой, которые сложно воспроизвести в приложении.

Mock hard

Документация вариантов использования в виде историй#

Сохраняйте варианты использования в виде историй на простом JavaScript, чтобы вернуться к ним во время разработки, тестирования и контроля качества.

story

Ускорение своего рабочий процесс с помощью надстроек#

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

addons

Внешний вид визуального теста#

Пользовательский интерфейс Pinpoint изменяется с точностью до пикселя, сравнивая снимки изображений историй.

pinpoint

Функциональность модульного тестирования#

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

unit test

Тест доступности#

Ознакомьтесь с историями о проблемах WCAG и ARIA с аддоном A11y.

Storybook

Документируйте пользовательский интерфейс, чтобы поделиться с вашей командой#

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

Storybook

Получите своевременную обратную связь во время разработки#

Опубликуйте Storybook в Интернете, чтобы дать вашей команде универсальный ориентир для обратной связи.

Storybook

Совместное использование компонентов между экранами и приложениями#

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

Storybook

Автоматическое создание документации пользовательского интерфейса#

Напишите Markdown / MDX для создания настраиваемого сайта для библиотек компонентов и систем проектирования с помощью дополнения Docs.

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

Так же как и отделить верстку от экранов - это приоритетная граница на первом шаге разработки приложения. На этом шаге закладывается компонентная разработка на уровне дизайна приложения. Программисту даже не нужно придумывать названия компонентов, так как они написаны на артбордах в программе Sketch App или Figma. В среднем, в день, можно сверстать 3-6 компонентов. Благодаря этому мы можем посчитать человеко-часы разработчика на создание UI-кита, а далее и всего приложения.

ModelDevs!

При разработке с помощью React Native вам необходимо вручную настроить приложение, чтобы оно отлично смотрелось на экранах разных размеров. Это утомительная работа, поэтому react-native-size-matters предоставляет несколько простых инструментов, которые значительно упростят масштабирование. Идея состоит в том, чтобы разработать один раз на стандартном мобильном устройстве с экраном ~ 5 дюймов, а затем просто применить предоставленные утилиты, поэтому размер артборда в Sketch для дизайна 320x568px.

Переходим к созданию технического задания на разработку компонентов UI Components в Storybook.

Для этого экрана мы реализуем две TypeScript модели:

TypeScript модель компонента Txt#

import { StyleProp, TextStyle } from 'react-native'
type sizeType = 'xLarge' | 'large' | 'medium' | 'small'
interface TxtT {  h0?: boolean  h1?: boolean  h2?: boolean  h3?: boolean  h4?: boolean  h5?: boolean  h6?: boolean  color?: string  textAlign?: string  title: string  numberOfLines?: number  ellipsizeMode?: 'head' | 'middle' | 'tail' | 'clip'  textStyle?: StyleProp<TextStyle>}

TypeScript модель компонента Avatar#

import { StyleProp, ViewStyle, TextStyle } from 'react-native'
type sizeType = 'xLarge' | 'large' | 'medium' | 'small'
interface AvatarT {  loading: boolean  avatar: string   onPress?: () => void  size?: sizeType  viewStyle?: StyleProp<ViewStyle>}

Скорость - 3 - 6 компонентов в день 

Шаг 2 - Прототип - Навигация - GraphQL модель экрана#

Компиляция на экранах - модель экрана - это сумма моделей экрана компонентов на экране. Создаются экраны они же артборды в Sketch, где мы объединяем компоненты и позиционируем их относительно друг друга. На этом этапе подключается навигация. В результате у нас готовый прототип, который можно согласовать с клиентом. Благодаря тому, что компоненты типизированы TypeScript, мы можем сложить модели компонентов на экране и поставить задачу на разворачивание бэкенда с помощью фреймворка AWS Amplify. Изначально GraphQL разрабатывался для облегчения работы фронтендеров и в тоже время стал языком общения serverless архитекторов AWS, где типизированные модели стали строительными блоками.

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

ModelDevs!

type History @model @auth(rules: [{ allow: owner, ownerField: "owner", operations: [create, update, delete] }]) {  id: ID!  step: Numbers!   cube: Numbers!  plan: Numbers!}
type UserProfile @model @auth(rules: [{ allow: owner, ownerField: "owner", operations: [create, update, delete] }]) {  id: ID!  avatar: String!  firstName: String!  lastName: String!  plan: Numbers!}

Скорость - 3 - 6 экранов в день

Шаг 3 - Логика - Деплой модели#

Так как код клиента в AWS Amplify генерируется автоматически, так же как клиент к нему, то после того, как заказчик принял прототип, подключается клиент к серверу путем публикации схемы на сервере командой amplify push.

deploy

Скорость - 5-10 минут, так как сразу деплоиться схема с шага два и при этом код для создания запросов на сервер писать не надо, так как работает кодогенерация. Весь деплой это GraphQL модель из шага 2 отправленая одной командой amplify push.

Подробнее и о том как задеплоить схему читать здесь

Иногда вы попадаете в ненадежную ситуацию, но вам лучше подождать дольше, чем явно провалить операцию. У Apollo есть apollo-link-retry который обеспечивает экспоненциальный откат и запросы на сервер между попытками по умолчанию. Правда он (в настоящее время) не обрабатывает повторы для ошибок GraphQL в ответе, только для сетевых ошибок. У Redux, MobX понятное дело под капотом этого решения нет так как они не клиенты и приходится задействовать сторонние мидлвари, по причине того, что REST как дедушка на пенсии с поддержкой любимых внуков.

Подробный разбор GraphQL vs REST.

ModelDevs!

В AWS Amplify есть функция DataStore, которая не только аналог apollo-link-retry, а также в нее встроенна настраиваемая привычная модель программирования с автоматическим контролем версий, обнаружением конфликтов и разрешением в облаке. К тому же больше не нужно писать дополнительный код, для отправки запроса на сервер после выхода приложения в онлайн, так как он идет из коробки в форме кодогенерации. Папка с моделями models и папка graphql генерируется автоматически - это слой клиента на все возможные CRUD - Create Read Delete.

DataStore

DataStore

Правда в AWS Amplify Create и Update это один метод DataStore.save.

Serverless

Создание бэкенда на AWS Amplify — это работа с бессерверной (англ. serverless) технологией, поэтому перед тем, как продолжить, мы с вами разберемся с тем, что такое бессерверные вычисления и в чем их преимущества над серверными.

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

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

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

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

Cloud Programming Simplified: A Berkeley View on Serverless Computing

Бессерверные вычисления#

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

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

Cloud Programming Simplified: A Berkeley View on Serverless Computing

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

Преимущества бессерверной архитектуры:

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

Один язык программирования#

С помощью современных инструментов и методологий, таких как AWS Amplify, один разработчик может использовать свой существующий набор навыков и знания единой платформы и экосистемы (например, TypeScript) для создания масштабируемых приложений, в комплекте со всеми функциями, которые в прошлом потребовались бы команды высококвалифицированных бэкэнд программистов и инженеров DevOps для сборки и обслуживания.

Меньше кода#

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

Отсутствие необходимости управлять серверами#

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

Масштабируемость#

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

Скорость разработки#

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

Эксперименты#

Если вы не тратите много времени на создание повторяющихся функций, вы можете экспериментировать легче и с меньшим риском. При отправке новой функции вы часто оцениваете риск (время и деньги, связанные с созданием этой функции) с возможным возвратом инвестиций (ROI). Поскольку риск, связанный с испытанием новых вещей, снижается, вы можете испытать идеи, которые в прошлом, возможно, не видели свет. Мы также можем гораздо проще протестировать различные идеи.

Безопасность и стабильность#

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

Автоматический контроль доступности#

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

Стоимость#

При традиционном подходе вы часто платите за вычислительные ресурсы независимо от того, используются они или нет. Это означает, что если вы хотите убедиться в том, что ваше приложение будет масштабироваться, вам необходимо подготовиться к самой большой рабочей нагрузке, которую вы могли бы увидеть, независимо от того, достигла ли она этого уровня. В конце концов, этот традиционный подход означал, что вы платите за неиспользованные ресурсы большую часть срока службы вашего приложения. С бессерверными технологиями вы платите только за то, что используете. С FaaS (Function-as-a-Service) вам выставляется счет на основании количества запросов на ваши функции и времени, которое требуется для выполнения кода вашей функции. С такими управляемыми сервисами, как Amazon Rekognition, вы платите только за обработанные изображения, минуты обработки видео и т. д., Опять же, платя только за то, что вы используете. Счет от вашего облачного провайдера — это только часть общей стоимости вашей облачной инфраструктуры, а также заработная плата. Эта стоимость уменьшается, если у вас меньше оперативных ресурсов. Есть также затраты на разработку. Создание приложений таким способом ускоряет вывод на рынок, сокращая общее время разработки и, следовательно, стоимость разработки. В общем вы платите за стабильную пропускную способность или время исполнения, а не за количество используемых серверов.

Подробнее о ценах здесь

Вывод#

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

References:#

Стадии рождения новой функциональности в программном продукте

Cоздание дизайн-систем с помощью Atomic Design

Атомарный дизайн (Atomic design)

GraphQL: Core Features, Architecture, Pros and Cons

GraphQL: A data query language

GraphQL