У приложений будущего может не быть бэкенда

История циклична.

Я создал свой первый веб-сайт в 1999 году с помощью самых передовых технологий, доступных веб-мастерам (не могу использовать слово разработчики в данном случае): редакторы WYSIWYG.

Веб-сайты представляли собой набор статических HTML-страниц с JavaScript и яркими GIF-файлами, которые переполняли интернет 2000-х годов, и обслуживались статическими хостерами, например, GeoCities.

В течение следующих лет появились лучшие варианты, такие как Macromedia Dreamweaver MX (теперь Adobe), выпущенный в 2002 году. Его самым большим преимуществом была улучшенная совместимость сгенерированного кода со стандартами.

Десять лет спустя, в 2009 году, я перешел к созданию динамических веб-сайтов. Все страницы создавались на стороне сервера с использованием PHP. Но и не только его: разработчики создавали full-stack веб-приложения на .NET, Java, Python, Ruby…

Эти технологии были не новы: ASP существует с 1996 года, а PHP впервые появился в 1994 году! Однако именно в 2000-е годы эти технологии стали доступны для большего числа небольших команд и индивидуальных разработчиков.

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

В то время облачные вычисления были еще относительно новым явлением и представляли собой инфраструктуру в качестве сервиса.

Перенесемся в настоящее время. 2019 год, а разработчики… снова создают статические сайты. Однако теперь все по-другому: веб-браузеры стали более эффективны, чем 20 лет назад, благодаря новым стандартам HTML, JavaScript, CSS и API.

Мы можем создавать сложные приложения, которые работают в веб-браузере, и при этом не нужно полагаться на внешние плагины. (Мы также вернулись к использованию большого количества GIF-файлов, но теперь делаем это ради смеха!)

JAMstack и изолированный фронтенд

Первый проект HTML5 был опубликован в 2008 году, и с тех пор производители браузеров постоянно внедряют новые веб-стандарты и добавляют API в сеть.

Начиная от более «базовых» элементов, таких как тег <video>, который внес значительный вклад в гибель Adobe Flash, до предлагаемых фундаментальных изменений в способе создания сети, таких как WebAssembly, разработчики с трудом успевают следить за новшествами.

Однако одним из самых значительных достижений стала популяризация новой парадигмы дизайна для веб-приложений, которая получила название JAMstack: JavaScript, повторно используемые API и предварительно визуализированный Markup.

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

Концептуальный обзор архитектуры приложений JAMstack

Часть JAMstack, состоящая из JavaScript, должна говорить сама за себя: все приложение выполняется на стороне клиента, представленного веб-браузером, и работает на JavaScript.

«А» — это самая интересная часть, обозначающая API: именно они делают приложения JAMstack интерактивными и обеспечивают отличное взаимодействие с конечными пользователями. Статическое приложение может взаимодействовать с другими сервисами через API, которые вызываются через HTTPS.

Например, API RESTful, которые легко создавать и использовать. В последнее время набирает популярность GraphQL, который отлично подходит для данных, представленных графами (не случайно он был изобретен в Facebook).

Для некоторых сценариев, таких как приложения, которые обмениваются большими объемами структурированных данных, используются буферы протокола и gRPC. Однако в настоящий момент им требуется прокси-сервер для работы с веб-браузерами.

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

Одной из важных деталей является то, что API могут принадлежать кому угодно. Приложение может взаимодействовать с API, которые вы создали и поддерживаете. Или вы можете использовать сторонние API, например, те, которые предлагают приложения SaaS. Мы рассмотрим их позже.

И, наконец, буква «M» в JAMstack обозначает предварительно визуализированный Markup. Веб-приложения — это статические HTML-файлы, которые предварительно визуализируются во время сборки различными инструментами связывания, такими как webpack, Parcel или Rollup.

Содержимое также может отображаться из файлов Markdown, например, как это происходит в генераторах статических сайтов, таких как Hugo, Gatsby и Jekyll. Вся предварительная обработка выполняется на компьютере разработчика или на сервере непрерывной интеграции (CI) до развертывания приложений.

После компиляции приложения, написанные с использованием JAMstack, представляют собой набор файлов HTML, JavaScript и CSS со всеми ассетами (изображения, вложения и т. д.). Отсутствие обработки на стороне сервера предоставляет приложениям JAMstack значительные преимущества.

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

Статические файлы можно получать из дешевых и надежных сервисов хранения облачных объектов, таких как Azure Blob Storage или AWS S3.

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

После размещения CDN (Content Delivery Network) перед хранилищем объектов сайт обслуживается и кэшируется несколькими конечными узлами с минимальным временем ожидания для посетителей по всему миру и невероятной масштабируемостью.

Вы также можете передавать файлы через Inter-Planetary File System (IPFS).

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

Прошли времена монолитных приложений со сложными шаблонизаторами (помните PHP?), которые представляли головную боль для обеих команд.

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

Компиляция для фронтенд-приложений выполняется очень быстро, и нет необходимости беспокоиться о контейнеризации, container orchestration, Kubernetes и т. д.

Учитывая насколько стандартизированы инструменты, настроить конвейер непрерывной интеграции и непрерывной доставки (CI/CD) не представляет трудности благодаря готовым шаблонам.

Все дело в скорости

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

Приложения работают быстро по трем причинам.

Во-первых, само приложение загружает данные асинхронно, поэтому пользователи могут видеть интерфейс во время загрузки и взаимодействовать с ним. Посмотрите на GIF загрузки нового приложения Twitter:

Новое приложение Twitter загружается мгновенно и запрашивает данные асинхронно

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

Вторая причина — возможность всестороннего кэширования приложения. Во многих приложениях JAMstack файлы JavaScript и CSS изменяются достаточно часто, поэтому клиенты могут длительное время кэшировать их после загрузки.

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

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

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

И наконец, серверу API не нужно тратить время на создание и обслуживание полных HTML-страниц. Он просто отвечает необработанными данными (обычно полезной нагрузкой JSON, сжатых с помощью GZIP), предоставляя клиенту возможность создать страницу.

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

Собственные API больше не нужны

Аутентификацию пользователей можно осуществлять с помощью внешних провайдеров. При создании корпоративного приложения директория уже находится внутри Azure AD или директории G Suite (или синхронизирована с ними).

Для потребительских приложений можно войти в систему с помощью социальных провайдеров, таких как Apple, Facebook, GitHub и т. д.

Такие компании, как Auth0 и Okta, предлагают мощные расширяемые решения, включающие управление учетными записями (формы регистрации, сброс пароля…) и интеграцию с внешними провайдерами.

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

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

Измерять посещаемость веб-сайта можно с помощью Google Analytics или Adobe Analytics. А такие сервисы, как Disqus или Commento, предоставляют пользователям возможность комментировать сообщения в блоге.

Для динамического изменения содержимого веб-сайта есть несколько вариантов среди «headless-систем управления содержимым». Например, Strapi и Ghost. Даже вездесущий WordPress можно использовать в headless-режиме.

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

Эти сервисы также содержат облачное хранилище в OneDrive и Google Drive, поэтому их можно применять для хранения и извлечения данных.

Разработчики также могут использовать внешние сервисы для таких действий, как прием платежей по кредитным картам (Stripe), конвертация файлов и создание миниатюрных эскизов для изображений (например, CloudConvert), обработка видео, отправка сообщений (например, через Slack, Teams, Twilio и т. д.).

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

И, наконец, некоторые «low-code/no-code» сервисы также можно использовать для обработки, которая должна происходить в серверной среде. Например, при необходимости подключить сервисы, к которым клиенты не могут получить прямой доступ (базы данных, некоторые корпоративные приложения и т. д.).

Одним из таких решений является Azure Logic Apps — IFTTT для разработчиков и предприятий, который можно запустить с помощью вызова REST.

Трудно не заметить преимущества использования API, предлагаемых внешними сервисами, поскольку они избавляют от забот о доступности и масштабируемости.

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

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

Если приложение находится только на стороне клиента и не хранит никаких данных, бремя соблюдения GDPR ложится на сервисных провайдеров, так же как использование внешних сервисов для платежей, таких как Stripe, освобождает от необходимости придерживаться PCI-DSS.

Конечно, вы также можете создать собственные API при отсутствии других вариантов.

С бессерверными платформами, такими как AWS Lambda и Azure Functions, не нужно управлять собственными серверами и масштабировать их, хотя ответственность за некоторые действия по-прежнему лежит на вас.

Эти действия включают в себя исправление приложения, обеспечение работы в поддерживаемой среде выполнения (например, переход на обновленную версию Node.js, когда у использованной версии закончился срок службы), и при необходимости выполнение гео-репликации развертываний и распределения нагрузки между ними.

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

Что может быть дальше: «JEMstack»

Создание веб-приложений с JAMstack на основе собственных и/или сторонних API на данный момент является одним из наиболее продвинутых шаблонов проектирования в веб-разработке.

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

Осталась только одна часть, требующая серверы — API. Следующий логический вопрос, на который следует искать ответ: «Каким образом можно полностью уйти от серверов?»

Ответ может предоставить использование блокчейнов, в частности Ethereum.

Я предлагаю назвать это «JEMstack»: аббревиатура для JavaScript, Ethereum и предварительно обработанного Markup.

Этот стек будет частью «сети 3.0» или распределенной сети. Распределенные приложения JEMstack (или dapps) будут обслуживаться через IPFS, а их данные будут храниться в блокчейне в виде распределенного регистра.

Некоторые из преимуществ включают предоставление контроля над данными пользователям и избавление разработчиков от забот об инфраструктуре.

Но мы еще не дошли до этого этапа. Однако dapps, созданные с использованием блокчейнов, уже существуют: список можно найти на App.co. Тем не менее до распространения подобных технологий необходимо решить еще множество вопросов.

Опыт разработчика (DX) при создании приложений на основе Ethereum действительно хорош.

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

Умные контракты могут хранить данные и выполнять вычисления на них и обычно пишутся с использованием похожего на C языка — Solidity.

Тем не менее на момент написания этой статьи, опыт конечных пользователей (UX) все еще нуждается во множестве улучшений, что является основным препятствием для широкого распространения dapp, которое, вероятно, будет преодолено еще не скоро.

Для начала большинству пользователей потребуется установить расширения браузера для взаимодействия с Ethereum, таких как Metamask для Firefox и Chrome и Tokenary для Safari. Менее популярные браузеры, такие как Brave и Opera, предлагают встроенную поддержку кошельков Ethereum.

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

Затем пользователям приходится иметь дело с кошельками Ethereum. В то время как чтение данных из Ethereum является бесплатным и простым (и не требует взаимодействия с пользователями), запись в блокчейне требует одобрения пользователей вручную и как минимум «оплаты газа».

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

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

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

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

Всплывающие окна подтверждения — распространенная часть Metamask UX

Существует огромное сообщество, которое работает над улучшением UX для приложений блокчейна: упрощением добавления идентификаторов, созданием более прозрачных процессов, ускорением транзакций и т. д.

Как и в случае с любой технологией, находящейся в состоянии разработки, у нее есть множество конкурентов. Возможно, в ближайшие месяцы и годы мы увидим больше конвергенции и стандартизации, и, в конечном итоге, dapps, написанные на «JEMstack», превратятся в новую норму.

---

Перевод статьи Alessandro Segala: Your Next App May Not Have a Back End