Для чего нужен React
Начнём с того, что вспомним, что такое React.js, или просто React. React — это JavaScript-библиотека, используемая для быстрой и удобной разработки динамических интерфейсов, выполняющих разные задачи, или скрипты.
Когда пользователи делают что-то с элементами интерфейса, они запускают эти задачи: браузер посылает запрос на сервер, сервер обрабатывает запрос и берёт из базы данных то, что нужно, чтобы пользователь увидел поставленный им лайк в соцсети, выбранные им товары в корзине интернет-магазина, наложенные эффекты в браузерных редакторах для работы с фотографиями, результаты теста и прочее в зависимости от задач приложения.
Как работает React
React использует подход рендеринга на клиентской стороне. Браузер получает с сервера HTML, CSS и JS-файлы, а потом запрашивает у сервера только те данные, которые необходимы для отрисовки изменений в интерфейсе страницы, произошедших в конкретную минуту.
Пример: Что нужно запросить от сервера, если пользователь ставит лайк чьему-то посту и больше ничего не делает на этой странице? Правильно — только функцию, которая увеличит количество лайков. За счёт этой экономии запросов и ответов снимается нагрузка на сервер, что делает из React инструмент для разработки сайтов, которыми, по задумке их владельцев, должны одновременно пользоваться тысячи, сотни тысяч и миллионы людей. Этот подход также даёт разработчикам возможность строить на React не весь сайт, а только его динамические элементы.
Из-за рендеринга на стороне клиента сайты на чистом React плохо индексируются поисковиками, но положение спасает подход Server Side Rendering и работающий на базе React фреймворк Next.js как инструмент для выполнения этого подхода.
По сравнению с обычными сайтами у сайтов на React более чистая архитектура. Какое значение имеет это замечание для нашей статьи, вы узнаете дальше.
React — это фронтенд или бэкенд? Может ли React быть использован для разработки бэкенда? Ответ: нет, это инструмент исключительно для разработки интерфейса.
Как организовать бэкенд
Вне зависимости от того, выбираем мы для клиентской части React или что-то другое, общие принципы работы над серверной частью можно свести к следующим:
- На выбор серверных технологий влияет предполагаемое количество пользователей, специфика проекта и результаты нагрузочного тестирования.
Для разработки серверной части используются разные языки с разной потребляемостью серверных ресурсов. Если в проекте предполагаются высокие нагрузки или большие объёмы данных, это нужно учитывать при выборе технологий. На бюджет это тоже влияет: можно почти до бесконечности масштабировать правильно спроектированное приложение, но есть языки, способные сформулировать ту или иную бизнес-задачу таким образом, чтобы она отнимала от процессора и оперативной памяти компьютера меньше ресурсов, и тогда эти вычисления будут стоить меньше.
- Данные между клиентом и сервером передаются по протоколу HTTP.
Протокол передачи данных — это язык общения между компьютерами, объединёнными в систему. Назначение этих систем влияет на выбор протокола. Если говорить про обмен данными через интернет, то для этого используется протокол HTTP или же — впрочем, сейчас это уже является санитарной нормой — его безопасная разновидность HTTPS.
- Серверную часть приложения, в основном, пишут на языках PHP, Python, Ruby, C# и JavaScript.
Какой язык для бэкенда выбрать? Справедливости ради, ни один из этих языков не был задуман как язык строго для одной среды — даже популярнейший в бэкенд-разработке PHP. Все они в разной степени годятся для разработки всего подряд: десктопных приложений, видеоплееров, текстовых редакторов и т. д. Но именно JavaScript изначально разрабатывался как язык для браузера, чтобы программировать взаимодействие пользователя с элементами интерфейса, но потом и он стал языком общего назначения благодаря Node.js, которая превращает его в универсальный машинный код.
Казалось бы, если клиентская часть приложения написана на React, то в стек для бэкенда нужно брать что-то ориентированное на JavaScript, например, Node.js. Так ведь? Не совсем. Если говорить про бэкенд для приложения, у которого отдельно клиент и отдельно сервер, то основное, что стоит определить — это как они будут общаться.
И здесь, наконец-то, пора коснуться поговорить о чистой архитектуре.
Архитектура React-приложений
Приложения с чистой архитектурой проще поддерживать, в них проще отслеживать и править баги. Построив такое приложение, разработчик контролирует потоки данных, разметку и стилизацию и в идеале знаком с паттернами программирования, позволяющими собирать приложения быстрее и гибче.
Для приложения с чистой архитектурой характерны:
- читабельный код. Пришедший на проект новобранец быстро в него вольётся, если увидит, что здесь используются знакомые ему практики;
- расширяемость. Даже в разгаре процесса можно что-то изменить или добавить к тому, что уже было сделано;
- оптимизированная работа. Быстрое приложение приятнее медленного.
Что тогда такое чистая архитектура React-приложений?
Клиент и сервер (фронтенд и бэкенд соответственно) — это хоть и связанные, но разные приложения. Для фронтенда не так важны детали реализации бэкенда, как важен API (Application Programming Interface) — набор соглашений между клиентской и серверной частью об использовании определённых процедур для выполнения операций с определённым результатом в конце. Достигнув этого соглашения, их можно разделить и разрабатывать параллельно. Это одна из особенностей разработки на React.
В погоне за чистотой архитектуры бэкенд и фронтенд часто разделяют, потому что с ростом монолитного приложения поддерживать его становится всё сложнее и сложнее.
Возьмём тот же Drupal, где обе эти части близко связаны. Скажем, на сайте есть форма, в которой надо что-то поменять, и велика вероятность, что разработчику нужно менять в настройках CMS отображение формы. Если разработать пользовательский интерфейс на React, то все нужные изменения в форме пройдут на клиентской стороне, без привлечения сервера. То же самое на бэкенде.
Пример: Есть интернет-магазин, в котором изменилась логика начисления скидки или доставки. При разделённом фронтенде и бэкенде разработчик делает изменения на бэкенде, но отображения это может не касаться.
Архитектурные стили API
Мы говорили о том, что с точки зрения архитектуры программных продуктов фронтенд и бэкенд рассматриваются как два самостоятельных приложения. Общение между ними происходит через соглашение под названием API.
Итак, актуальные на сегодняшний день архитектурные стили API — это:
- SOAP,
- REST API,
- GraphQL.
Подробнее рассмотрим архитектурные стили API.
SOAP
SOAP (Simple Object Access Protocol) — это протокол взаимодействия веб-сервисов друг с другом или с клиентами. По этому протоколу работает веб-сервис SOAP API, который используется для обмена сообщениями между серверами.
Если сложить главные недостатки SOAP в один, то можно сказать, что для обмена данными нужно писать громоздкие сообщения исключительно в формате данных XML и получать один ответ на один запрос. Большие сообщения нагружают трафик и, соответственно, сервер, что не делает протокол удобным в контексте проектов для массового использования. Но он всё ещё применяется во внутренних корпоративных приложениях вроде приложений для банков.
REST
REST (или RESTful) — это архитектурный стиль для создания API с помощью протокола HTTP. Аббревиатура расшифровывается как Representational State Transfer.
REST API поддерживает не только формат XML, но и JSON, TXT, CSV, HTML, а вместо сложного XML-запроса клиенту нужно просто передать правильный URL. Например, если пользователь хочет посмотреть данные о конкретном товаре, то при клике на него клиентская сторона формирует URL в качестве запроса к серверу на получение данных (GET-запроса), куда включён ID этого товара. Это делает способ лёгким и понятным, снимает нагрузку на сервер и, как следствие, позволяет создавать масштабируемые приложения с высокой производительностью.
Ситуации, в которых применяется REST:
- ограниченная пропускная способность соединения с сервером,
- необходимость кэшировать запросы,
- масштабирование проекта в будущем,
- общение клиента и сервера происходит по методу AJAX.
Приложение Scrapi, разработанное ADCI Solutions— пример одностраничного приложения, использующего стиль REST на бэкенде.
GraphQL
GraphQL называют по-разному. Кто-то говорит, что это язык запросов для API-интерфейсов и среда, в которой они выполняются. Кто-то (например, наша студия) называет это описанием стандарта, которое можно реализовать разными способами. В любом случае, это следующая ступень эволюции клиент-серверного общения и наш личный фаворит.
На фоне своих предшественников у GraphQL ещё более конкретные и экономные запросы к серверу. Когда на проекте много ресурсов и используется архитектурный стиль REST API, клиент обращается к нескольким точкам входа (endpoints), в то время как через GraphQL клиент отправляет запросы только через одну точку входа и формулирует, какие данные и в каком формате он хочет получить.
Пример: Есть React-приложение — агрегатор магазинов электронной техники. По специальным правилам, которые предписывает стандарт GraphQL, клиент отправляет серверу JSON-запрос данных о модели телефона и магазинах, в которых она продаётся. Если сервер правильным образом написан и сконфигурирован, то он поймёт запрос и пришлёт всё, что нужно. Следовательно, главная фишка GraphQL в том, что клиент сам может выбрать, какие данные ему нужны от сервера.
У GraphQL есть три типа запросов:
- query — запрос на получение данных,
- mutation — запрос на обновление данных после каких-то операций типа создания заказа,
- subscription — автоматическое уведомление клиента через WebSocket-соединение о том, что произошли какие-то изменения, и данные на странице надо обновить.
Чем так интересно WebSocket-соединение? Большинство протоколов не держат двери для данных нараспашку: клиент посылает запрос, сервер отвечает — всё, соединение можно закрыть. Но для постоянного обмена данными был создан WebSocket, протокол на базе HTTP. Этот протокол, в отличие от соединения по обычному HTTP-протоколу, не закрываются после ответа сервера, и поэтому незаменим на таких проектах, как онлайн-игры, интернет-магазины, чаты и прочих, где клиент и сервер должны обмениваться данными постоянно. Разумеется, для создания интерактивных и высоконагруженных React-приложений он тоже подходит.
Преимущества GraphQL:
- не нужно создавать несколько REST-запросов. Чтобы извлечь данные, достаточно ввести один запрос — даже если данные лежат в разных источниках;
- не привязан к конкретной базе данных или механизму хранения;
- GraphQL использует строгую систему типов данных, определяющую различные форматы данных, которые используются в приложении.
Так как GraphQL — это не конкретная разработка, а, скорее, стандарт, то нужен инструмент для его реализации. Один из способов реализации — библиотека управления состоянием Apollo, состоящая из двух библиотек: Apollo Client и Apollo Server.
Backend-for-frontend
Не обязательно, чтобы твой сервер с данными и бизнес-логикой был частью приложения. Сейчас популярностью пользуется паттерн Backend-for-Frontend (BFF), представленный компанией Soundcloud в 2015 году. Его суть в том, что бэкенд может быть написан на чём угодно и может отдавать данные как угодно, но они с фронтендом всё равно будут понимать друг друга, потому что на бэкенде GraphQL работает как отдельный сервис, забирающий данные с сервера и отдающий их клиентской стороне.
Представьте, что у вас старый проект с легаси, где клиент и сервер общаются через SOAP. С паттерном BBF не нужно переписывать весь бэкенд — достаточно лишь добавить прослойку на GraphQL. Что до новых приложений, то в них, разумеется, есть смысл использовать GraphQL сразу.
Заключение
Бэкенд любого приложения любит внимательное отношение к подбору технологий для своей разработки. Критерии для выбора базы данных и серверной технологии следующие:
- задача;
- ресурсы (команда и бюджет),
- ожидаемый уровень нагрузки на приложение,
- количество пользователей,
- объёмы и сложность обработки данных.
Использование React на фронтенде не определяет выбор технологии для бэкенда. Во-первых, обмен данными через WebSockets можно построить и на Node.js, и на Python, и на C#. Во-вторых, хотя с фронтендом и бэкендом, написанными на JavaScript, ваш fullstack-разработчик и будет чувствовать себя на своём месте, метод Backend-for-Frontend тем и хорош, что позволяет сделать между клиентом и сервером прослойку на GraphQL и не задумываться о совместимости технологий с обеих сторон.
Иными словами, используя ряд уже известных ноу хау, бэкенд для React-приложения можно построить на всём, что популярно, что используется, что нравится команде, которая предлагает услуги разработки на React.js, и с чем она умеет работать.
