Наша команда-партнер Artmisto
За последние годы разработка веб-и кроссплатформенных приложений претерпела качественный скачок благодаря появлению фреймворков и библиотек javascript, спонсируемых основными игроками в мире технологий (Google, Facebook, LinkedIn, ...).
При выборе технологического стека необходимо учитывать множество факторов , таких как возможности и опыт нашей команды, масштаб проекта, различные платформы, на которых мы хотим присутствовать, или поддержка, которую предоставляет сообщество. к этим технологиям, которые позволят нам иметь лучшую документацию, обучение и, наконец, более широкий круг разработчиков на рынке, которые могут участвовать в нашем проекте.
Еще одна очень важная переменная, о которой обычно забывают до тех пор, пока она не становится проблемой, - это позиционирование в поисковых системах нашего приложения, поскольку во многих случаях и в зависимости от цели проекта оно может стать чем-то критическим.
Такие технологии, как Angular, React, Vue, Polymer или Ember, не являются "дружественными к SEO" по своей природе, поскольку они основывают свою работу на рендеринге клиентов (CSR) , который имеет множество преимуществ (простота инфраструктуры, скорость, простота разработки, ...), так как некоторые недостатки, которые мы подробно опишем ниже.
Источник: преимущества рендеринга на стороне сервера по сравнению с рендерингом на стороне клиента
Хотя основные поисковые системы (Google, Yahoo, ...) утверждают, что рассматривают приложения как «стандартного» пользователя , было доказано, что результаты не такие, как ожидалось, и приложения в конечном итоге подвергаются наказанию, терпя резкое падение позиционирование.
С целью смягчения этих проблем появились вспомогательные технологии, которые позволяют рендерить наши серверные приложения javascript (SSR), предлагающие пользователям (людям и роботам) конечный HTML, что облегчает читаемость для поисковых систем и повышает скорость и, Таким образом, пользовательский опыт.
Источник: преимущества рендеринга на стороне сервера по сравнению с рендерингом на стороне клиента
Решение может быть, априори, старым, и заставит нас переосмыслить технологический стек , который может привести к возвращению на стол технологий прошлого, благополучно преодоленных (PHP + jQuery, WordPress, ...), которые в итоге породили такие проблемы, как управление инфраструктуры и масштабируемости приложения.
Эти недостатки устраняются путем разработки приложений SPA, основанных на статических файлах, которые облегчают их публикацию с использованием недорогих и полностью масштабируемых решений для хранения, дополненных CDN, такими как S3 и CloudFront в Amazon Web Services.
Повторное введение серверов рендеринга в уравнение вместо безсерверных решений, подобных тем, которые разрешены приложениями SPA, несомненно, является неудобством, которое следует принимать во внимание, но они не должны пугать нас, так как возможности разнообразны и многие существующие технологии они позволяют нам противостоять вызову с достаточными гарантиями успеха.
Для разработки нашей архитектуры в качестве примера мы будем использовать приложение, ориентированное на электронную торговлю , например, магазин одежды.
Источник: собственная разработка
Игнорируя требование позиционирования в поисковой системе, хорошее (на AWS) решение, простое и традиционное, может быть следующим:
Как видите, есть два приложения. Первый - это онлайн-магазин, доступный и ориентированный на широкую публику. Он состоит из SPA, разработанного на любом javascript для фреймворка / библиотеки (Angular, Vue, React, ...), рабочая версия которого находится в службе управляемого хранения, как это было бы S3 в Amazon Web Services. Мы защитили решение с помощью брандмауэра безопасности и CDN, чтобы повысить производительность и кэшировать наше приложение.
Кроме того, у него есть API, который предоставит нашему приложению всю информацию , что не является основанием для анализа в этой статье.
Есть еще одно частное приложение, бэкэнд нашего проекта, которое позволит нам управлять интернет- магазином, добавляя новые товары , акции, управление платежами и т. Д. Архитектура приложения аналогична, но, очевидно, только авторизованные пользователи смогут получить к нему доступ.
Эта архитектура обеспечит простоту, эластичность, безопасность и оптимальную производительность (при условии, что API также соответствует этим принципам), но она не решит требование позиционирования.
Чтобы справиться с проблемой, мы можем сделать это несколькими способами. Одним из них будет перенаправление трафика, создаваемого роботами (поисковыми системами и т. Д.), На сервер, который позволит нам выполнять рендеринг на сервере. Это хорошее решение, поскольку инфраструктура не требует большой сложности, поскольку объем посещений будет очень небольшим.
Это решение может быть распространено на всю публику, что, очевидно, требует большей инфраструктуры. Это можно проверить с помощью CDN, что значительно сокращает количество запросов.
Думая об отсутствии сервера , мы могли бы адаптировать наше приложение рендеринга для работы в функционально-ориентированном сервисе, таком как Api-Gateway + NodeJS (SSR) в Lambda. Вероятно, это не лучший дизайн для продуктивного проекта.
Пожалуй, самое элегантное решение, которое положительно скажется на всех наших пользователях, - это отображение на сервере определенных частей приложения, которые должны быть проиндексированы поисковыми системами, таких как продукты, категории и т. Д.
Это был бы способ решения проблемы, не требующий изменений в других частях архитектуры. Реактивный способ поднять это был бы следующим:
Источник: собственная разработка
На диаграмме в виде обновления статьи / категории в DynamoDB (база данных, управляемая AWS) запускается событие, которое выполняет функцию Lambda, которая позволяет нам рендерить на сервере страницу статьи, которая подверглась изменениям.
Этот HTML-файл размещается в том же контейнере, который содержит веб-страницу, и становится доступным для всех пользователей , что сокращает время загрузки статьи.
Это также решает проблему позиционирования, поскольку роботы будут посещать те же HTML-файлы , которые содержат всю необходимую информацию для правильной индексации продукта.
Уточните, что у нашего куска будет очередь для тех процессов, которые могут завершиться с ошибкой (Dead-Letter Queue), и это нужно «спасти».
Поэтому выбор программного обеспечения не был бы критическим, поскольку в последние годы появились различные решения, которые отвечают на эту новую проблему и позволяют нам разрабатывать «универсальные» или «изоморфные» приложения относительно простым способом.
Universal Angular, Rill Framework, Nuxt, Fast-Boot или другие технологии хороши для того, чтобы реагировать на то, что казалось проблемой, что, как мы видели, является просто требованием, которое нужно принимать во внимание, к которому можно подходить с разных и творческих подходов. пути.
Изображение: pexels.com
Проверьте другие сообщения BBVA Next Technologies:
