Что такое Rest API (http)? Soap? GraphQL? Websockets? RPC (gRPC, tRPC). Клиент - сервер. Вся теория

Приветствую вас друзья и в этом видео мы будем говорить о взаимодействии клиента и сервера поговорим о различных протоколах о архитектурных стилях взаимодействия клиента и сервера поговорим про веб сокеты про язык Граф ql про удалённый вызов процедур рассмотрим как теоретически визуально наглядные примеры так и посмотрим на реальный код ролик старался сделать максимально понятным наглядным и чтобы его приятно было смотреть Не только начинающим но и более продвинутым поэтому от тебя как обычно я попрошу всего лишь лайк комментарий чтобы это видео лучше продвигалась Ну и на этом всё меньше слов больше дела приступаем Итак начнём с плана на

урок начнём Мы конечно сведения поговорим про клиент-серверное взаимодействие в целом про основу всего это http протокол архитектурные стили и так далее дальше будем рассматривать уже конкретные сценарии поговорим конечно же про rest App про swap про graphql про Web сокеты про rpc на примере grpc и trpc сразу добавлю что прямо в какие-то дебри мы здесь углубляться не будем здесь будет ролик больше обзорный про разные технологии Но если вам нужно про какой-то отдельный вариант например про graphql или про веб сокеты или про rpc записать какой-то отдельный подробный углубленный ролик обязательно пишите об этом в комментарии и я

над этим подумаю Итак двигаемся дальше более даточные зрители наверняка сейчас зададут вопрос почему я http протокол объединил с архитектурным стилем пи или же например с Граф Клем с языком запросов ведь по сути это вообще разное И на самом деле они отчасти будут правы Однако всё что вы видите на слайде объединяет то что так или иначе это всё определяет способ общения клиента и сервера и именно об этих способах общения мы сегодня и будем говорить Итак начнём с самых-самых основ поговорим в целом про клиент-сервер ную архитектуру в такой архитектуре сервер выступает источником скажем так вычислений хранения данных

какой-то бизнес-квартал взаимодействия определяет AP о котором мы дальше тоже будем говорить и клиент в этой всей архитектуре с помощью каких-то определённых действий Может с сервером общаться может попросить какие-то данные у него и сервер ему эти данные вернёт И самое главное что всё это работает в формате запрос ответ То есть клиент данные попросил сервер эти данные вернул И как вы понимаете речь идёт не только про данные Мы также можем серверу сказать выполнить какое-то действие например зарегистрировать нового пользователя провести оплату добавить товар в корзине и соответственно сервер уже определяет может он выполнить это действие или не может

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

нашему серверу за какими-то данными или просит выполнить его какое-то действие при этом для клиентов в большинстве случаев Сервер - это такое единое цельное Вот как я уже сказал какое-то монолитное приложение источник бизнес данных но при этом сам сервер под капотом может быть большим распределенным состоящим из нескольких микросервисов но при этом клиента это особо волновать не должно Ну и в общем подытожим клиент - это у нас потребитель а сервер поставщик с клиент-серверной архитектурой думаю Понятно теперь поговорим про основу всего про то на чём в принципе основан весь веб это http http - это протокол гипертекстовый транспортный

протокол который находится на самом верхнем уровне Модели osi Модели tcp IP это прикладной уровень или уровень приложений как его по-другому называют именно с помощью http общаются большинство приложений в интернете первоначальная идея http - это обмен гипертекстовыми документами то есть нашими HTML ками которые мы так хорошо все знаем но сейчас с помощью http можно по сети передавать практически любые данные те текстовые файловый HTML xml json В общем практически любой формат теперь поговорим про структуру самого http и посмотрим на пример запроса Самый классический базовый запрос выглядит примерно вот так сходу для тех кто никогда этого раньше не

видел выглядит достаточно страшно поэтому Давайте Разобьём http запрос на составные части и посмотрим на структуру первая строчка http запроса - это Стартовая строка и состоит Она из трёх частей Первое - это метод второе - это URL и третья - это версия http здесь я извиняюсь при монтаже сделал ошибку заметил уже достаточно Поздно всё переделывать не хочется URL здесь - это СШ Login а версия - это http с10 то есть здесь вот в серединку вот в этот URL попал http ошибочно Итак метод - это грубо говоря семантика запроса что мы хотим сделать создать какой-то ресурс обновить

его или же получить в данном случае пост говорит нам о том что мы хотим какой-то ресурс создать или выполнить какое-то действие про методы мы более подробно чуть позже поговорим URL - это то куда мы отправляем запрос в данном случае мы отправляем его на СШ Lin тем самым сервер понимает Какое именно действие Мы хотим сделать Ну и далее указывается версия http ну здесь думаю всё понятно со стартовой строкой разобрались теперь посмотрим на следующую часть структуры http это заголовки так называемые хедеры заголовки несут достаточно важную информацию в них есть часть заголовков обязательных и часть заголовков необязательных в

том числе можно составлять какие-то свои кастомные заголовки в заголовках указывается информация о Хосте с которого был отправлен запрос информация о браузере или о типе устройства с которого отправляется запрос тип контента например н текст или какой-то другой тип также могут отправляться различные авторизационные заголовки с токенами также с помощью заголовков обеспечивается безопасность взаимодействия различных источников сети так называ называемый Корс заголовки которые отвечают за безопасность общения разных источников которые расположены на разных доменах и третья часть любого http запроса - это тело сообщения в нём клиент отправляет серверу какие-то данные которые ему необходимы и Давайте этот запрос Расшифруй сообщении

мы отправляем логин пользователя и пароль для того чтобы сервер мог этого пользователя распознать то есть давай Давайте ещё раз рассмотрим наглядно клиент отправляет Запрос который выглядит как раз таким образом как мы сейчас рассмотрели сервер должен вернуть ему ответ ответ немного отличается от запроса и выглядит он примерно таким образом из отличий сразу бросается в глаза что Стартовая строка выглядит немного по-другому Всё дело в том что в ответе стартовой строки Нет она называется строка статуса статус L в ней мы видим также версию http и так называемый статус код который определяет успешно был выполнен запрос или же нет

также в ответе можно заметить такие же хедеры заголовки но они могут отличаться от тех которые были в запросе то есть есть заголовки запроса и есть заголовки ответа И точно также есть тело сообщения в котором сервер возвращает клиенту какие-то данные теперь поговорим про важную часть http - это методы та самая часть стартовой строки о которой мы говорили ранее методов достаточно большое количество но мы сейчас разберём только основные которыми чаще всего оперирует разработчик Итак это методы Get Post Put Patch и Delete в зависимости от того какой метод указал клиент сервер будет обрабатывать запрос по-разному семантически каждый из

них выполняет какое-то определённое действие Get предназначен для получения данных например запросить список товаров запросить список пользователей запросить какую-то информацию расширенную по конкретному товару пост чаще всего предназначен либо для создания ресурса либо для выполнения какого-то действия как например логин который мы рассматривали ранее т и пач предназначены для обновления ресурса но семантически они тоже разные Т обновляет ресурс целиком а патч как правило обновляет только часть ресурса Ну из delit думаю всё понятно он предназначен для удаления какого-то ресурса удалить пользователя удалить товар со стартовой строкой http запроса разобрались Теперь давайте разберёмся со строкой статуса которую возвращает сервер уже

в виде ответа и здесь самой важной частью для нас является статус код который сообщает нам о том как именно был обработан запрос существует пять групп этих статус кодов Первое - это информационные они всегда начинаются с единички например сотый статус код 101 102 и так далее те статус коды которые начинаются с двойки обозначают что запрос выполнился успешно двухсотый статус код думаю так или иначе встречал абсолютно каждый статус коды которые начинают Со стройки обычно означают какой-то редирект перенаправление например мы успешно залогинится на другую страницу статус коды которые начинаются с четвёрки и с пятёрки обозначают что запрос был

обработан с ошибкой причём если статус код начинается с четвёрки то это значит что Ошибка клиента например клиент передал неправильные данные думаю 404 легендарный статус код который говорит о том что какой-то ресурс не найден видели также все А статус коды которые начинаются с пятёрки - это ошибки сервера например клиент передал данные все корректные но на сервере написали неправильный код там что-то сломалось и сервер соответственно возвращает пятисотый статус код обычно это называют сервер пятисот опять же статус коды - это про семантику то есть ничего не мешает нам например на сервере выполнить какое-то действие с ошибкой но вернуть

двухсотый статус код но так Обычно никто не делает то же самое и с методами ничего не мешает нам сделать так чтобы Get запрос у нас создавал какой-то ресурс а не возвращал какие-то данные но опять же так никто не делает Ну давайте рассмотрим ещё примеры каких-то статус кодов тот самый легендарный 404 not found когда мы не нашли ресурс РСО статус код чаще всего говорит что запрос был некорректным то есть опять же это всё про семантику ничего нам не мешает всегда щат четыр сотый статус код на все клиентские ошибки но мы их подразделялись код говорит об Успехе

Д1 о том что ресурс был успешно создан пятисотый о том что это внутренняя ошибка сервера Итого мы уяснили что семантика здесь очень важна и хотелось бы иметь определённый набор правил какой-то архитектурный стиль который говорит нам о том как делать правильно А как неправильно И для этого существует rest архитектурный стиль проверенный временем который сообщает нам о том как наиболее эффективно общаться клиенту и серверу по http и перед тем как говорить про сам ре Давайте разберём вообще понятие AP расшифровывается оно как Application programming интерфейс то есть из названия уже понятно что это некоторый интерфейс который описывает то

как с программой стоит общаться И это интерфейс именно программный то есть ещё как альтернативу можно привести графический интерфейс то есть мы вот открываем приложение нажимаем на какие-то кнопочки взаимодействуем с графическим интерфейсом тем самым мы сообщаем программе Какие действия Мы хотим выполнить а AP - это именно программный интерфейс который как бы предоставляет способ взаимодействия с этой программой Ну и предлагаю сразу рассмотреть на конкретном примере допустим у нас есть программа обратившись к которой мы можем сделать следующие действия во-первых получить актуальный курс валют переконвертировать одну валюту в другую и допустим получить прогноз погоды на неделю и Допустим мы

хотим получить прогноз погоды на неделю для этого сервер нам должен предоставить какой-то интерфейс с помощью которого мы можем это сделать и описание этого интерфейса из описания мы понимаем что мы должны отправить Get запрос по такому-то URL в ри параметрах указать дату на которую нам нужен прогноз и город для которого мы этот прогноз хотим получить а сервер в свою очередь в качестве тела ответа вернёт нам в виде массива состоящего из объектов в котором есть время температура Будет ли дождь и так далее всю необходимую для нас информацию Ну исходя из того что мы видим мы понимаем что

отправив запрос соответствующими параметрами мы получим соответствующий ответ это и есть а то как мы взаимодействуем с сервером Ну и хорошая пишка всегда предоставляет хорошую документацию где подробно расписан список методов так называемых эндпоинт мы можем постучать онное действие и также должно быть описание Что ожидается на вход для этого энпо и Что ожидается на выходе Итак с вводной частью мы разобрались теперь переходим непосредственно кре многие ошибочно называют это протоколом Но это далеко не протокол протоколом в данном случае выступает http - это архитектурный ль набор правил который описывает то каке использовать http И строить свою ашку так чтобы

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

системы то есть по rest система может иметь энное количество вот этих вот самых слоёв причём с точки зрения клиента это вообще никакой роли не играет то есть с точки зрения клиента эта вся система она как бы цельная едина Разно а внутри там может быть Сколь угодно много слоёв с каким-нибудь балансирования распределением проксирование с какой-нибудь микросервисной архитектурой думаю Тут всё понятно двигаемся дальше и третья концепция говорит нам о том что сервер не должен обладать каким-либо состоянием и что это значит давайте рассмотрим на примере клиент отправляет запрос сервер возвращает ему какой-то ответ и при этом никакого промежуточного

состояния не запоминается именно с точки зрения сервера какие-то данные могут внести там в БД в кэш ещё куда-то это мы не рассматриваем то есть подразумевается что при каждом следующем запросе клиенты сервер общаются как будто бы в первый раз и для того чтобы сервер идентифицировать клиента для того чтобы сервер понял что ему необходимо сделать Какие данные вернуть какую операцию произвести клиент должен отправлять всю необходимую полную информацию для того чтобы сервер смог этот запрос обработать и выполнить это в принципе одна из самых важных концепций Ну думаю для ребят которые уже Немного в теме варятся Здесь всё понятно

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

и удаление то есть опять же если сущностью является товар то мы должны уметь его первое добавить второе удалить третье обновить какую-то информацию об этом товаре четвёртое мы должны уметь получить список этих товаров то есть массив И пятое мы по какому-нибудь ID товара должны получить информацию именно по конкретному одному товару и как с такими операциями нам вообще взаимодействовать ранее мы рассматривали http методы Post Delete Put Patch и Get я говорил что каждый из этих методов обладает определённой семантикой то есть пост - это создание Delete удаление Put Patch обновление Get соответственно получение то есть для каждой крут

операции мы используем семантически правильно http метод Далее для каждого товара для каждой сущности У нас есть определённый URL по которому мы с ней взаимодействуем в данном случае для товаров это URL products и Обратите внимание что во множественном числе так по Репе более правильно называть вот эти URL для эндпоинт и Обратите внимание если мы хотим получить информацию по конкретному товару то у нас в конце добавляется ещё СШ ID то есть идентификатор этого товара также там может быть sln СШ ещё какой-то от атрибут по которому мы делаем поиск Но вообще выглядит это всё Вот так и вот

именно такая работа со всеми эндпоинт и есть тот самый единообразный унифицированный интерфейс сюда же можно ещё добавить формат взаимодействия какой-нибудь json xml заголовки которые требуются для например авторизации пользователя какой-нибудь токен опять же не может быть такого что у вас в одном эндпоинт он называется там autorisation token а в другом там X token например то есть всё должно быть единообразно в одном стиле в соответствии с правилами которые диктуют репи там есть ещё на самом деле вот в этом вот пункте про единообразный интерфейс и другое описание другие моменты но я не считаю нужным их в этот ролик

добавлять потому что они только запутаются хочется также дополнительно акцентировать ещё раз на этом внимание что запрос должен содержать всю необходимую информацию для его выполнения мы не можем просто взять и сказать серверу создай товар Там просто отправив какой-нибудь пост запрос мы должны предоставить всё необходимое что требуется для сервера чтобы он этот товар смог создать то есть помимо самого пост запроса мы должны также указать информацию о товаре в теле запроса указать соответствующие заголовки метод указать соответствующий URL и только тогда когда мы передали всю необходимую информацию сервер сможет этот запрос обработать также очень важный момент про который я

уже тоже говорил это семантика То есть например с помощью Get запроса мы должны получать данные а изменять удалять или создавать мы не должны Хотя в теории чисто технически мы можем так сделать ничего не мешает нам вообще использовать на всё гет запросы и любую операцию делать через них это ну в принципе http Это позволяет Но вот эта вот семантика rest - это как раз вот про семантику про наиболее эффективное использование http мы нарушим поэтому для каждого эндпоинт мы используем семантически правильный метод если с Get и пост запросом всё понятно чи создать ресурс то спут немного всё

сложнее есть такое понятие как идемпотентность запросов причём какие-то запросы считаются идемпотентный ими быть Априори не могут Давайте разберём это понятие метод http считается идемпотентный если Повторный запрос сделанный несколько раз подряд имеет один и тот же эффект То есть если мы пытаемся обновить какой-то ресурс и отправляем один и тот же запрос с одинаковыми данными на обновление то сервер должен выполнить этот запрос одинаково то есть не должно быть такого что первый запрос сделал одни действия второй запрос сделал другие действия в итоге как бы результат у нас непредсказуемый То есть если прямо зачитывать определение то идемпотентность - это

свойство которое означает что повторно идентичный запрос сделанный несколько раз подряд имеет один и тот же эффект и не изменяет состояние сервера корректно реализованные методы Get Put и Delete идемпотентный Но вот пост например идемпотентный по своей По большей части быть не может Давайте опять же на наглядном примере разберём Почему так если мы отправим пост запрос с одинаковыми данными несколько раз подряд сервер создаст У нас четыре разных ресурса то есть результат здесь уже Ну отчасти конечно предсказуемый но не совсем то есть ресурсы всё равно создаются разные эффект происходит не один и тот же именно поэтому пост запрос

не идем потенте и Давайте посмотрим теперь на примере путь запроса если мы меняем возраст у какого-то ресурса например там пользователя с 10 на 20 а потом ещё трижды отправим такой же пут запрос с попыткой заменить возраст на 20 у нас ничего не произойдёт сервер не создаст нового ресурса не удалит его Он просто обновит тот же самый атрибут у какого-то объекта у какой-то сущности двигаемся дальше Пятая концепция Пи - это кэширование причём кэширование может быть осуществлено средствами http за счёт проставления определённых заголовков так и средствами какими-то сторонними реализованными на сервере использование какого-нибудь Ready smem cash и

так далее причём опять же важный момент с точки зрения семантики опять же в первую очередь что Get и пост запросы могут кэшировать а Put и Delete не могут рассмотрим на примере что вообще кэширование подразумевает представим что у нас есть сервер и миллион клиентов одновременно или не одновременно с каким-то промежутком времени запрашивают у нас список валют с помощью гет запроса Согласитесь что список валют меняется крайне редко и каждый раз нам прямо полноценно отправлять запрос полноценно ходить в базу данных полноценно доставать этот список валют чтобы вернуть его клиенту смысла особого не имеет и поэтому мы можем иметь

кэш опять же это кэш может быть реализован с помощью http заголовков и результаты этого кэша будут храниться Например у нас прямо в браузере либо с помощью каких-то сторонних Шей которые реализованы на сервере например redis и вот на примере http заголовков мы указали что мы хотим зашивать результат сохранили где-то его в браузере нас это не особо интересует где это всё хранится это подкапотные скажем так махинации но теперь в следующий раз когда наш клиент запрашивает список валют мы смотрим Что он у нас находится уже в кэше и не отправляем запрос на сервер повторный А достаём из кэша

То есть это происходит намного намного быстрее и как такой второ степенный Побочный вариант это снижает нагрузку на сервер в качестве примера тоже можно что-нибудь такого привести вот Представьте что у вас выключатель света находится в самом конце комнаты и вам Каждый раз когда вы там встаёте с кровати или там Заходите в комнату приходится до этого выключателя идти включать или Выключать свет а в качестве кэша можно привести такой пример что вот например вы настроили Умный дом и вы с любой точки комнаты можете там сказать какую-то команду Алиса Включи свет и свет у вас включится то есть своего

рода такая оптимизация вашего времени вот с кшм в принципе тоже самое мы не ходим каждый раз в базу данных не отправляем каждый раз запрос а достаём данные которые редко меняются из этого кэша теперь поговорим про формат обмена данными между клиентом и сервером вообще по сту можно обмениваться практически любыми данными но в большинстве своём это json но также достаточно часто используется и xml сейчас на слайде Вы можете увидеть пример мля и вот они с джином в данном случае по наполнению по самим данным равны как я уже сказал чаще всего используют Jon но xml однако тоже встречается

особенно в какой-то сфере финтеха банковской сфере xml достаточно распространён ещё позже в рамках супа поговорим про xml поподробнее следующий важный момент о котором стоит поговорить - это версионирование сразу рассмотрим на примере представим себе ситуацию что у нас есть какой-то набор эндпоинт мы с ним работаем У нас есть какие-то клиенты которые эти эндпоинты используют и в какой-то момент Нам необходимо внести какие-то правки в нашу опиш Но эти правки не обратно совместимы То есть например Мы хотим убрать вообще метод удаления пользователя или как-то изменить формат общения и если Мы это сделаем прямо в текущем коде В текущей

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

свойственно в принципе любому AP но у реста есть даже определённый спецификации потому как стоит документировать и описывать ваше AP и здесь стоит обратить внимание на Open AP это спецификация и sager Давайте о них поговорим Open - это спецификация которая позволяет вам задокументировать опиш то какие у вас есть эндпоинты какие методы Какие статус коды Какие ри параметры ожидаются на вход Какое тело запроса Какое тело ответа будет вам возвращено Какие ошибки Вы должны обработать и так далее версия AP в том числе в общем всю всю-всю необходимую информацию для того чтобы вы с этой ашкой смогли начать работать

про Open поговорили Теперь поговорим про sager sager по сути это имплементация Open это скажем так набор инструментов для документации и визуализации нашего rest выглядит это дело всё вот таким образом в большинстве своём на всех языках программирования во многих фреймворка есть инструментарий который позволяет автоматически почти без каких-либо дополнительных действи генерить на основе ваших эндпоинт всю эту документацию Вы можете её только как-то дополнять и на этом попе всё перед тем как переходить к суа предлагаю подвести итоги Итак модель взаимодействия по пе - это клиент-сервер система может быть многоуровневой или многослойный Называйте как хотите также пи не должно

обладать каким-то состоянием каждый раз клиенты сервера общаются как в первый раз ста должно обладать единообразным унифицированным интерфейсом про это мы говорили более подробным также может быть AP кэширует обмена данными чаще всего Jon Ашка должна быть версионирование в ней не должно происходить Ну и в идеале конечно ваша опиш должна быть задокументировано и на этом с репи мы заканчиваем и переходим к swap как мы выяснили рест - это не протокол это архитектурный стиль набор правил в свою очередь SW - это уже протокол обмена структури сообщениями если в рее у нас может быть любой формат данных json xml

либо какой-то ещё то в swap это xml если быть точнее soap xml со своей спецификой при этом Как я рассказывал в своих архитектурных скринкаста Никто не запрещает вам в рамках одного приложения в рамках одного сервера в рамках одного бэнда реализовать и rest и soap то есть у Вас бизнес логика - это какое-то отдельное ядро есть рест контроллеры которые возвращают G есть suap контроллеры в которых описан wsdl и которые возвращают xml если rest - это набор правил по эффективному использованию http то suap в свою очередь может использоваться с любым протоколом прикладного уровня smtp FTP http и

другие для описания соа сервисов используется wsdl о нём я чуть ранее уже упоминал это определённый язык который основан на xml и выглядит это всё Примерно вот таким вот образом здесь нет эндпоинт в классическом понимании как в rest здесь есть так называемые операции вот нас интересует больше Центральная часть данного слайда операция или множество дверей Каждую из которых мы можем открыть в свою очередь suap - это скорее одно окно в которое Нам необходимо передать название процедуры название операции которую мы хотим выполнить суа в отличие от ре обладает определённой строгостью потому что СТ - это всё-таки какой-то набор

правил архитектурный стиль а сап - это уже протокол который задаёт определённые рамки определённые границы и сообщения которые отправляются в соа обладают определённой структурой состоят они из четырёх частей три обязательных и одна опциональная она отвечает за ошибки на слайде как раз отображены три обязательные части предлагаю по каждому кратенько пройтись и разобрать для чего это нужно envelop - это корневой элемент который определяет начало и конец сообщения именно благодаря нему клиент понимает когда сообщение полностью получено header - это что-то типа заголовков в обычном http запросе даёт нам возможность определять какие-то дополнительные свойства для приложения например опять же отправить

какой-то токен указать тип формата сообщения и любую другую вспомогательную информацию Ну и третий обязательный элемент сообщения - это тело в котором мы передаём уже какую-то полезную нагрузку какие-то полезные данные если кратко пробежаться по soup то это всё что можно сказать Кому интересно можете изучить уже более подробно Но если кратко подытожить то опять же СТ - это просто набор рекомендаций в целом со свободной структурой и суа свою очередь - это уже протокол который определяет строгие правила строгую структуру и загоняет нас в определённые границы здесь описываются сервисы с помощью wsdl и сообщения обмен сообщениями происходит в формате

xml часто swap используется как я говорил ранее уже в банковской сфере на этом soap мы заканчиваем и переходим к Гра ql по Граф ql у меня на канале есть отдельный практический ролик рекомендую к просмотру но а сейчас мы разберём теоретическую часть начнём с того что gql - это уже не архитектурный стиль и не протокол gql - это язык вопросов и предлагаю для лучшего понимания начать с проблематики представим что у нас магазин электроники который мы кстати разрабатывали в одном из видео на моём канале и здесь есть страница детального просмотра информации по конкретному товару Здесь запрашивается много

данных всяких характеристики описания стоимость в общем много-много всего по конкретному товару также у нас есть другая страница где мы отображая товары уже списком и здесь Нам необходимо запросить мало данных то есть нам достаточно отобразить модель товара там его рейтинг и например стоимость можем Ещё немного поим провизию и представить что у нас есть третья страница например какая-нибудь админка Где нам нужно отобразить данные в виде таблицы какой-нибудь для админов И там нам нужно уже больше данных так вот при классическом подходе нам бы пришлось делать следующее либо у нас был бы один endpoint который возвращал бы массив абсолютно

всех данных которые нам нужны то есть объект со всеми вложенными полями которые нам даже могут быть в конкретном запросе не нужны либо же нам на кэндес бы делать разные эндпоинты вот здесь вот я в примере привёл Little Data Big Data Ну конечно так никто не называет это просто для примера то есть в одном запросе мы возвращаем нужные данные для одной страницы в другом запросе нужные данные для третьей страницы для четвёртой и так далее То есть это не оптимальный подход и хотелось бы иметь возможность чтобы клиент сам определял Какие данные ему в конкретном месте нужны то

есть схематично мы хотим иметь какую-то такую картину клиент отправляет запрос за продуктами за товарами и говорит Дай мне данные с идентификатором названием и стоимостью и на сервере все лишние данные характеристики отбрасываются и возвращаются товары только с теми полями которые мы запросили и вот Граф ql как раз для этого и предназначен если при классическом подходе сервер определяет схему и формат данных которые возвращаются в конкретном эндпоинт то в graphql сервер как раз определяет только схему данных а Клиент уже сам запрашивает те данные те поля те характеристики те атрибуты которые ему требуются в одном запросе нужно три поля

из объекта запрашиваем три в другом нужно 23 значит можем запросить все 23 поля в graphql есть два основных вида запроса это quy и мутации quy - это аналог Get запроса Мутация - это аналог пост запроса то есть с помощью quy мы какие-то данные получаем с помощью мутации либо создаём либо меняем также есть ещё subscription - это realtime какие-то изменения своего рода подписка на изменения данных подписки сделаны поверх веб сокетов о которых мы позже будем также говорить теперь давайте посмотрим как с этим всем работать в первую очередь описывается схема данных в принципе это похоже на обычные

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

1.000 и хотим запросить не и рост при этом какие-то часто запра данные часто запрашиваемые поля мы можем вынести в так называемые фрагменты и использовать их в разных запросах ну здесь думаю всё понятно это сделано для того чтобы мы могли какие-то части не описывать каждый раз заново а переиспользовать в одном месте в другом месте в третьем месте с quy и с фрагментами Надеюсь всё понятно теперь давайте поговорим о мутациях Мутация - это по сути тоже обыкновенный самый запрос но который как-то данные мутирует изменяет создаёт что-то выполняет какое-то действие обновляет Като сущность и так далее на слайде

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

вход и то что возвращают все эти ри или эти мутации то есть Get All users возвращает массив пользователей Get User возвращает по шнику конкретного пользователя и мутация Вот с таким вот интом создат нам пользователя Как видите здесь в принципе максимально просто интуитивно Понятно далее описываются сами эндпоинты бизнес логика какая-то здесь мы по айдини пользователя находим здесь возвращаем всех пользователей А здесь пользователя создаём добавляем его в массив там присваиваем какой-то идентификатор с базой данных взаимодействуем потом указываем URL по которому будет всё это дело доступно указываем схему и запускаем сервер и далее по вот такому вот пути

который мы указали вот здесь вот как видите GRA ql это вот это значение которое мы передали вот здесь нам будет доступна Вот такая своего рода админка здесь мы можем посмотреть все запросы все мутации посмотреть какого типа у нас данные и что удобно это всё Мы отдаём фронту и фронт Сам определяет Какие данные ему нужны соответственно он может запрашивать только то что требуется ему в конкретной ситуации также всё можем посмотреть по мутациям поискам то что нам необходимо найти и в общем достаточно удобно этим всем пользоваться здесь же мы кстати Можем попробовать написать прямо за запрос давайте

это и сделаем попробуем написать какой-нибудь запрос при этом что важно в одном запросе мы можем запрашивать разные данные то есть мы можем делать такие комбинированные запросы указываем запрос за получением списка всех пользователей и мы хотим от бэнда получить ID username Ну и Давайте ещё возраст отправляем запрос видим что нам вернул энд пробуем запросить только айди ники видим что он вернул нам только айдини попробуем запросить ещё какую-нибудь вложенную сущность например дишни и заголовок отправляем запрос Ну да посты он вернул на потому что я их просто там не указал Но если бы они были то он бы

вернул нам посты только с указанными полями Ну и теперь обсудим преимущества которые gql нам предоставляет во-первых это частичная самодов все ции все инпуты все атпу это всё частично самодопомоги сво - это кодоева опять же за счёт строгой схемы мы можем генерировать в том числе и на фронтенде код и Фло работы здесь следующий мы описываем какой-то запрос например получить список всех туду ушек с такими-то полями далее запускаем определённый скрипти с помощью определённого инструмента указы путь до схемы после чего во-первых в базовом варианте нам наге нер автоматически все типы нам не придётся описывать их вручную и у

нас будет Ну практически полное соответствие типов на фронтенде и на кде но также это дело всё можно ещё потютьков в общем это тоже достаточно классная фича graphql следующее преимущество это ну наверное оно самое основное - это то что клиент запрашивает только нужные ему данные из этого вытекает как раз то что меньше трафика гоняется по сети мы не запрашиваем огромный набор данных мы запросили только то что нам нужно в конкретной ситуации это влияет Естественно и на скорость работы и на трафик который потребляется клиентом В общем сплошные плюсы В общем Подводя итоги Гра Классная штука всем как

минимум рекомендую попробовать и напоминаю опять же что у меня есть практический ролик на канале с созданием приложения Как серверного так и клиентского на graphql и на этом с graphql мы заканчиваем и переходим к веб сокета ве бсо - это также протокол Но в отличие от http в котором мы установили связь отправили какой-то запрос получили ответ И связь оборвали здесь устанавливается постоянное подключение в http конечно тоже бывают исключения о которых я также на своём канале в практическом ролики по realtime приложениям рассказывал но в классическом варианте всё-таки на каждый запрос устанавливается новое соединение в http и вот

websocket - это как раз протокол для realtime взаимодействия когда клиент и сервер за счёт постоянного соединения непрерывно обмениваются какими-то данными когда нужны веб сокеты это конечно же какие-нибудь чаты Где вы непрерывно обменивается сообщениями это какие-нибудь графики где нужно быстро показывать изменения например там курсы валют или на бирже когда цены на акции меняются постоянно в realtime Ну давайте наглядно посмотрим как это работает Давайте начнём с http опять же похожая схем У нас есть какой-то сервер который с базой данных общается здесь мы отправляем запрос получаем ответ и на этом соединение как бы обрывается При этом если подразумевала

какая-то широковещательная рассылка например отправка сообщение в чат То для того чтобы остальные программисты Вот на этом слайде получили это сообщение они должны его просить то есть отправить Повторный запрос в веб сокетах это работает немного по-другому все грубо говоря онлайн пользователи устанавливают соединение с сервером непрерывное соединение в котором и клиент и сервер постоянно обмениваются какими-то сообщениями и уже в данном случае если один пользователь отправляет сообщение на сервер ТО сервер со всеми с кем у него установлено подключение может сразу этим сообщением поделиться как я уже говорил ранее так называемая широковещательная рассылка И за счёт того что нам

не надо постоянно устанавливать соединение обрывать это соединение клиент с сервером могут вот в таком непрерывном формате я это наверное уже четвёртый или пятый раз говорю Однако это важно могут обмениваться сообщениями вот в таком двустороннем формате опять же Напоминаю что у меня на канале есть ролик Где мы создаём три чата realtime чата на разных технологиях это веб сокеты это лон Ping и Север Sense Event ролик длится буквально полчаса Однако пользы можно извлечь очень много если ранее вы с этим не работали опять же сейчас подсказка всплывёт и ссылка будет в описании и также ещё по веб сокета

У меня есть отдельный ролик Где мы создаём Paint onl это такой грубо говоря холст на котором сразу несколько человек что-то рисуют и сразу видят изменения которые на этот холст вносятся разными участниками Ну а сейчас давайте кратенько глянем на то как веб сокеты вообще работают это вот сервер простейшей создаём websocket сервер вешаем какой-то хендлер на подключение и на сообщение это события и соответственно эти сообщения мы как-то обрабатываем отправляем с клиента вот такое поле ивент по которому мы определяем какое действие должно выполниться подключение или же отправка сообщения также у нас есть вот такая широковещательная рассылка где мы

по всем онлайн клиентом проходим се в цикле и отправляем им сообщение То есть со стороны сервера Здесь всё элементарно просто Давайте посмотрим теперь на клиент здесь в принципе тоже всё просто устанавливаем соединение Обратите внимание что вместо http указываем vs Это протокол как раз указываем порт и как обычно подключаемся только в отличие от http опять же мы не на каждом запросе Это указываем только при подключении и затем вот в таком опять же событийном формате мы с этим взаимодействуем есть событие on Open on Mage on Close и onor соответственно каждое из этих событий мы можем обработать и

написать на это какую-то логику отправка сообщения установка подключения закрытие подключения опять же здесь мы так теоретически кратко смотрим Если хотите с тий то ссылочки будут в описании это ролики с канала Ну а Мы двигаемся дальше И теперь поговорим про удалённый вызов процедур про rpc в частности поговорим про grpc и про trpc Прежде чем говорить про конкретной имплементации Давайте вообще разберём понятие rpc как я уже сказал это удалённый вызов процедур И что это значит вот у нас есть клиент и есть сервер сервер реализует какой-то метод например Do something или там я не знаю добавить в корзину

или ещё какое-то действие при этом на клиенте этот метод не реализован но клиент с помощью специального объекта Так называемого стаба может этот метод вызвать и при этом он это делает так как будто бы этот метод реализован у него То есть это и есть удалённый вызов процедуры на самом деле там отправляется сетевой запрос сервер отправляет какие-то данные но с точки зрения клиента это всё происходит так как будто бы клиент сам вызвал эту процедуру и сам Ну выполнил какой-то действия на самом деле происходит именно вот такое удалённое взаимодействие то есть Давайте ещё раз более схематично посмотрим сервер

имплементировать какой-то метод с точки зрения rpc это называется процедуры и клиент эти процедуры удалённо может вызвать при этом с точки зрения его кода это выглядит как стап точка название процедуры название метода согласитесь Звучит достаточно удобно Давайте теперь поговорим про jpc jpc - это как раз фреймворк набор инструментов платформа можно по-разному назвать от Google и внутри себя она использует как раз вот эту технологию удалённого вызова процедур jpc очень популярен в микросервисной архитектуре И вот именно микросервисы друг с другом по jpc общаются чуть позже мы поймём Почему когда будем говорить о преимуществах Ну и например во всей

вот этой схеме микросервисы между собой общаются по HPC есть какой-то Proxy Gateway какая-то Входная точка которая может уже всё это по Репе отдавать куда-то в веб в мобилку и так далее но сами вот эти микросервисы Они общаются по grpc делают это супер эффективно и супер быстро за счёт преимуществ http2 и других преимуществ о которых мы позже поговорим Ну и Давайте сразу недалеко отходя от кассы О преимуществах сразу и поговорим поговорим о том что отличает jpc от классического подхода во-первых здесь используется http2 вместо http 1 http2 по тестам быстрее на 10-15 чем http1 вместо вместо текстовых

сообщений которые используются в http1 в http2 используется бинарный формат за счёт этого его можно лучше сжать лучше обработать быстрее отправить в http2 также реализованы потоки данных так называемый стриминг Он простой и супербыстрый также здесь вместо джисона который достаточно избыточный не сжимается используется бинарный формат как я говорил уже ранее он называется проба на него мы чуть позже тоже взглянем и поговорим о преимуществах также в grpc есть инструментарий из коробки это генерация кода для многих языков программирования То есть вы описываете определённый Файлик указываете что на входе что на выходе какие процедуры У вас есть внутри сервиса и

с помощью специального генератора с помощью специального компилятора который называется про C Вы можете наге нери код для разных языков программирования это тоже делает grpc таким более гибким более универсальным инструментом ну и соответственно как написано на слайде инструментарий с короб там есть аутентификация потоковая передача данных в том числе двунаправленная и много-много другого ну и соответственно всё это вот сам подход с удалённым вызовом процедур позволяет нам удобно эти процедуры вызывать То есть клиент вызывает процедуры так как будто бы они реализованы прямо у него теперь давайте взглянем на формат обмена данными на тот самый проба о котором мы

говорили ранее это простой бинарный формат за счёт того что он бинарный его можно сжать причём достаточно эффективно в отличие от того же джисона и он имеет строгую типизацию в отличии тоже от того же джисона в котором ты в одно поле можешь в массиве например в объектах в одном случае передать строку в другом Number в третьем вообще массив и строгой типизации это всё дела не имеет но есть нюанс с тем что сервер перед тем как отправить данные должен их сериализовать вот в этот вот формат проба а клиент должен эти данные уже 10 реализовать но за счёт

того что у нас нет такой избыточности как в Jon плюс Jon нельзя сжимать эффективно А мы получаем большой выигрыш в скорости очень большой Теперь давайте посмотрим на то как описываются файлики самими сервисами выглядит это Примерно вот так здесь у нас описан сервис с двумя процедурами у которых на вход мы ожидаем Hello request а на выходе Hello Reply с такими вот полями после того как мы описали этот самый лу код на многих языках программирования Что делает этот инструмент также универсальным пишем один прото файл гнем код на разных языках опять же для микросервисов Да и в принципе

для разработки супе удобно Я выкачал с официальной документации проекта nots Давайте на него взглянем вот тут вот лежат протоавис процедуры описывают что Они получают на входе и что отдают на выходе то есть здесь пример классического Hello world в обычном формате и в стримингового затем какие-то библиотеки что-то настраивается далее описывается Say Hello это соответственно имплементация самой процедуры здесь вызывается просто callback и передаётся сообщение Hello и name который мы получили в квесте Вот это тот самый реквест который мы описывали в профайлер прямо примитивный классический Hello world но нам для базового понимания хватит далее вот этот вот сервис

который мы в прото файле описали подключается указываются процедуры методы далее сервер запускается и теперь давайте посмотрим как клиент с этим всем работает опять же настраиваются какие-то библиотеки ещё что-то нас это особо не интересует но нас интересует вот этот момент мы создаём клиент из сервиса gritter И теперь мы можем удалённо процедуры вызывать то есть Обратите внимание мы вызываем процедуру так как будто бы мы вызываем её у этого клиента Client Say Hello мы не отправляем каких-то отдельных запросов Мы не описываем какие-то там http заголовки методы мы просто вызываем процедуру и передаём в неё аргументы в нашем случае

это request объект с полем name и callback в котором мы просто выводим в логи сообщение которое нам сервер как раз вернул Давайте теперь запустим сервер запустим клиент и мы видим Вот это самое сообщение то есть процедура была вызвана удалённо мы получили какой-то месседж и влоге его выли если вот тут юзернейм поменяем соответственно видим что нам сервер возвращает уже другое значение соответственно в процедуре может быть любая логика Сейчас мы по сути просто вызываем колб и передаём туда строчку сам медж но здесь может быть что-то посложнее Давайте теперь руками попробуем ещё одну процедуру добавить посмотрим как это

происходит добавляем сюда rpc say goodbye дублируем requ меняем у него название будет goodby request соответственно поля можно тоже какие-то другие добавить здесь у нас в принципе всё продублируйте можете абсолютно любую после того как вы описали профайлскул есть Статик код гн Ну давайте сейчас более быстрым путём пойдём нам здесь в принципе один метод добавить чтобы просто убедиться что это заработает Вот и Давай теперь на клиенте этот метод вызовем say goodby в логи передаём сообщение которое нам возвращает сервер Ну и Давайте запустим запускаем сервер и запускаем клиент и Как видите мы получаем два сообщения Hello Вася say

goodbye Вася Надеюсь какое-то базовое понимание grpc у вас сложилось чтобы вы примерно представляли что это такое и дальше могли уже изучить самостоятельно возможно когда-то я более подробный ролик про grpc практически запишу Ну и напоследок посмотрим на trpc относительно новый инструмент расшифровывается как typ Save rpc в принципе здесь Наверное какую-то теорию давать смысла нет Давайте посмотрим лучше сразу на пример также выкачал пример с официальной документацией здесь куча всяких примеров и Давайте посмотрим минимальный с использованием реакта начнём с сервера опять же сверху все необходимые импорты далее инициализируется сам tpc и нас интересует По большей части роутер здесь

описывается вот в таком формате то что мы ожидаем на входе сам inp и quy Это непосредственно сам запрос какая-то логика соответственно это всё можно вот так вот вынести отдельно позировать Ну понятное дело здесь сейчас оставим всё вот в таком вот виде и самое важное что мы здесь описываем схему того Какой объект мы ожидаем на входе Какой объект мы можем ожидать на выходе Давайте добавим здесь ещё какое-нибудь поле здесь вот как видите много вариантов того какой тип мы можем указать Bind Ray string и так далее можно указать какие-то модификаторы что Поле может быть пустым что Поле

может принимать такое значение такое значение и так далее соответственно здесь указывается тип этого атера создаётся HTTP сервер классический настраивается Корс и так далее Здесь всё в принципе по классике как в обычном каком-нибудь экспрессе Но что самое интересное - это то что на клиенте мы эти процедуры все можем удалённо как бы вызывать и при этом вся типизация сохранена вот здесь Обратите внимание используется react query настраивается вот этот trpc клиент через провайдер он прокиды ется в принципе всё по классике классический react в папочку utils Давайте ещё заглянем вот вот здесь создаётся trpc react и там указывается вот

этот самый аутер который мы с сервера импортировались мы просто вызываем какие-то необходимые для нас хуки Но что самое интересное что вся типизация сохранена Как видите автокот нам сразу подсказывает что у нас ожидается на вход поле name которое является строкой и поле value которое является массивом при этом за счёт вот этой строгой типизации Мы также сразу видим какой набор методов какой набор процедур у нас есть и эти процедуры мы можем вызывать сейчас у нас показывает что массив на вход ожидается типа any но это наверняка тоже как-то можно типизировать не знаю насколько это Production Ready технология насколько

она вообще хороша в продакшене Но опиш какие-то вот такие небольшие проекты думаю клепать можно очень быстро выглядит всё супердом особенно вот в связ с тем же react query выглядит классно Давайте попробуем какой-нибудь ещё метод какую-нибудь процедуру добавить посмотрим как всё это дело у нас подхватит на клиенте Ну да сразу видим что у нас появился метод goodby можем вызвать US quy ну и соответственно вся типизация работает Если мы какой-нибудь поле уберём то оно сразу же пропадает и с клиента и на этом всё друзья вот такой вот ознакомительный теоретический ролик у нас получился очень старался над визуалом

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