.webp)
.webp)
Межплатформенное программное обеспечение – термин, который довольно часто используется в веб-разработке. У него есть много значений в зависимости от контекста, чем он немного сбивает с толку.
Эту статью мы начнем с того, что определим этот термин, и продолжим обсуждением некоторых сценариев использования.
Изучив данную статью, вы сможете лучше вникать в обсуждения со своими коллегами, которые касаются технических и структурных аспектов. Вы также сможете разрабатывать более безопасные и надежные API и потоки данных.
Определение межплатформенного ПО
Межплатформенное ПО – это программное обеспечение, которое служит посредником между двумя приложениями или службами. Оно устраняет различные трудности их взаимодействия.
Вы можете представить, что это некий прокси-сервер, который выступает в роли накопителя данных, преобразователя или просто прокси-сервера, который перенаправляет запросы.
Распространенные сценарии использования межплатформенного ПО
Преобразователь
Существует большое количество форматов обмена данными, например, JSON, XML и Protobuf. Даже с учетом того, что сейчас мы в основном используем JSON, каждый из них имеет свои сценарии использования.
Например, считается, что Proto Buffers более производительны, нежели JSON, но при этом они не удобны для восприятия человеком. Получается, что вы можете использовать Proto Buffers для внутренних служб и JSON для случаев, когда пользователем API является браузер.
А теперь давайте предположим, что нам нужны обе эти службы, которые используют разные протоколы для взаимодействия друг с другом.
Мы можем создать межплатформенное программное обеспечение, которое использует библиотеку преобразования формата данных и преобразует запросы в формат, который будет понятен принимающей службе.
Накопление и дублирование данных
Архитектура на основе микрослужб – это популярный архитектурный шаблон, который в основном применяет в современных приложениях.
Если вы не знакомы с такой архитектурой, то это лишь значит, что ваше приложение состоит из множества независимых друг от друга маленьких приложений и служб, которые взаимодействуют через Интернет.
Например, в проекте, связанном с продажами через Интернет, у вас может быть микрослужба для добавления и извлечения товаров (Product), еще одна микрослужба для поиска (Search) и еще одна для аутентификации и хранения информации о пользователях (User). И при этом у каждой из них своя собственная база данных.
Давайте теперь представим, что мы хотим реализовать наш поиск так, чтобы мы могли найти и пользователей, и товары.
Если бы это было монолитное приложение, то можно было бы просто написать запрос для поиска в каждой таблице и объединить результаты. Но в данном случае наши базы данных работают на разных серверах.
Эту проблему можно решить несколькими способами. Мы рассмотрим два из них.
Накопление данных
Мы можем использовать межплатформенное ПО для того, чтобы отправить запросы на оба сервера и запросить выполнить поиск в их базах данных в соответствии с искомым словом.
В таком случае мы можем накапливать результаты, которые мы получаем c обоих серверов, и возвращать их клиенту. Отметим, что количество запросов увеличивается линейно по мере того, как мы увеличивает количество серверов (и при этом мы также должны объединять эти данные).
Дублирование данных
Мы можем хранить дубликаты данных на нашем поисковом сервере, чтобы он мог выполнять поиск самостоятельно без запросов к серверам, хранящим информацию о товарах и пользователях. Возможно, это менее эффективный способ с точки зрения занимаемой памяти, но он является более быстрым, а для поисковых служб решающее значение имеет именно скорость.
Если нам нужны таблицы Product (Товары) и User (Пользователи), то мы также можем создать эти таблицы на нашем поисковом сервере. В дальнейшем, когда мы будем сохранять информацию о новом пользователе в нашей базе данных пользователей, мы также будем сохранять ее копию и на поисковом сервере.
У нас есть два варианта. Первый заключается в том, что мы можем вызвать методы сохранения сервера Search с серверов User и Product, чтобы продублировать данные. Второй состоит в том, что мы можем создать межплатформенное ПО для того, чтобы хранит там данные. И оно будет делать следующее:
- При каждом запросе на сохранение, оно будет вызывать методы сохранения сервера Search и сервера User/Product.
- Если первое сохранение выполнилось неудачно, оно не будет вызывать методы сохранения на другом сервере (таким образом обеспечивается согласованность баз данных).
Давайте взглянем на две структурные диаграммы. На одной из них есть межплатформенное ПО, а на второй - нет. Вот так выглядит диаграмма без межплатформенного ПО:
Выглядит не очень, да? Что правда, то правда, это действительно выглядит ужасно, и такой подход сделает ваш код более сложным и сильно связанным.
А вот так выглядит аналогичное решение только с межплатформенным ПО:
В этом случае клиент просто вызывает межплатформенное программное обеспечение, чтобы сохранить информацию о товаре или пользователе, а оно уже делает все остальное.
Код, который выполняет дублирование данных, отсутствует как на серверах User и Product, так и на клиентской стороне. Это теперь забота межплатформенного ПО.
Безопасность API
Мы можем просматривать исходящие запросы для любого кода клиентской стороны. Сделать это можно либо в консоли браузера, либо через прокси-сервер.
Мы уже как-то говорили о пользовательском сервере, который обеспечивает вход в систему и регистрацию. Если наш клиентский код напрямую отправляет запросы на этот сервер, то он тем самым раскрывает адрес нашего сервера аутентификации. А если IP-адрес нашего сервера узнают злоумышленники, то они могут воспользоваться специальными инструментами, чтобы найти наши конечные точки и просканировать наш сервер на наличие уязвимостей.
Для того, чтобы скрыть URL-адрес нашего сервера аутентификации, мы можем использовать межплатформенное ПО в качестве прокси-сервера. Наш клиент будет взаимодействовать с межплатформенным ПО, а оно уже будет перенаправлять запрос на сервер аутентификации и возвращать ответ.
Такой подход также позволит нам блокировать любые запросы на наш сервер аутентификации, кроме тех, которые идут с URL-адреса нашего межплатформенного ПО. Это обезопасит наш сервер аутентификации.
Раньше это было бы невозможно, так как наш внешний интерфейс взаимодействовал с сервером аутентификации, а так как внешний интерфейс – это компьютер клиента, то у нас не было бы возможности применить IP-фильтр.
Предоставление общедоступных API
Их предыдущего пункта мы узнали, что межплатформенное ПО можно использовать в целях ограничения доступа к нашему API.
А теперь давайте взглянем на вторую часть этого уравнения: что если мы хотим предоставить доступ к нашему API, но при этом хотим, чтобы он был ограничен? А вдруг мы являемся системным программистом в банке, а банк планирует устроить хакатон. Ему будет необходимо предоставить доступ к своему API, верно?
Но поскольку это банк, то, очевидно, что он не может предоставить доступ ко всему API и разрешить все операции. Это значит, что необходимо найти такой способ, который позволит предоставить ограниченный доступ.
Для этого можно реализовать межплатформенное ПО, которое предоставит доступ лишь к некоторым конечным точкам и будет перенаправлять запросы в фактическому API банка. Таким образом, банк сможет предоставить этот API разработчикам на хакатоне.
Заключение
Мы начали с определения того, что такое межплатформенное программное обеспечение, и постарались распределить по категориям сценарии использования межплатформенного ПО в веб-разработке.
Имейте в виду, что это далеко не весь список сценариев использования, но я надеюсь, что, несмотря на это, он все-таки оказался для вас полезным.
