С тех пор, как в Facebook был открыт GraphQL с открытым исходным кодом, его популярность постоянно росла, и сегодня он стал практически повсеместным. Но что делает его таким популярным? Как он соотносится с архитектурой на основе REST и собирается ли он полностью заменить REST API? Вот что я думаю о GraphQL

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

GraphQL - это нечто особенное, и в нем не используются вещи, которые нам хорошо знакомы по REST API.

Это очень далеко от реальности и забавно, но именно так кажется людям, которые никогда не касались GraphQL и просто видели, как он работает на поверхности.

Что же тогда такое GraphQL?

Если бы я описал это сейчас в самых простых терминах, я бы сказал, что это всего лишь Спецификация. Действительно отличный способ использования существующих веб-технологий. По сути, запросы GraphQL - это просто HTTP-запрос Post к конечной точке API. Да, это запрос Post к конечной точке, предназначенный для работы с запросом, включая запросы GraphQL. Давайте быстро рассмотрим пример, создав сервер GraphQL.

Для простоты я буду использовать Node, но поскольку GraphQL сам по себе является средой выполнения. Неважно, на каком языке мы создаем API. Давайте быстро установим зависимости

yarn add apollo-server moment

И создайте простой GraphQL API

Чтобы запустить запрос

Подождите, это не то, как вы запускаете запрос в GraphQL!

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

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

Краткое примечание. Каждый запрос к GraphQL API классифицируется как запрос, включая мутации, подписки и сам запрос, если вы знаете, что это такое.

Является ли схема единственной причиной, по которой GraphQL настолько силен?

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

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

Для небольшого приложения это ничего не значит. Но для большого приложения всегда нужны наиболее оптимизированные решения. Сама по себе идея запрашивать только обязательные поля очень эффективна и, следовательно, всегда использовалась в традиционной архитектуре REST для создания маршрутов для получения определенных данных. Это работает без проблем для небольшого приложения и даже теоретически, но по мере увеличения размера приложения (рассмотрим Facebook) соединение проводов становится все более и более сложным, и вы в конечном итоге столкнетесь с ситуацией, когда вам придется снова перепроектировать всю систему. используя что-то вроде GraphQL или, возможно, в конечном итоге создадите другой GraphQL.

И есть еще много интересных вещей, которые GraphQL поставляет (например, подписки), но когда-нибудь их можно будет сохранить для других статей, потому что я хотел поговорить о том, лучше ли GraphQL, чем традиционные REST API.

Действительно ли GraphQL лучше REST и собирается полностью его заменить?

Я согласен с тем, что GraphQL является лучшей версией rest и действительно мощной альтернативой REST, но он не собирается заменять API ни сегодня, ни в ближайшее время. И тому же есть несколько причин.

Для небольшого приложения REST API может делать практически все, что и GraphQL API.

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

Вышеупомянутые причины объясняют, почему в корпоративном мире API GraphQL используются вместе с REST API.

Личный опыт работы с GraphQL

На личном уровне GraphQL - это мое первое предпочтение при создании API, и я действительно не создал ничего, что бы не включало то же самое в течение некоторого времени. Просто потому, что он добавляет лучший Full Stack DX.

Вы дошли до самого дна! Спасибо за чтение.

JavaScript на простом английском языке

Вы знали, что у нас есть три публикации и канал на YouTube? Найдите ссылки на все на plainenglish.io!