Представьте свой API как меню ресторана с GraphQL
Прочтите все меню, выберите свое любимое блюдо и присоединитесь к кухне GraphQL, где революция протокола связи API готовится на сильном огне.
Технология GraphQL - это язык запросов для предоставления доступа к вашему API. По сравнению с популярным стандартом REST, GraphQL предоставляет схему в одной конечной точке и предоставляет язык запросов для любого клиента (мобильного, веб-сайта и т. Д.) Для обращения к конкретным данным в API.
Когда мы говорим о конкретных данных, мы имеем в виду действительно конкретные. В то время как в REST конечные точки предоставляются, а информационный интерфейс определяется внутренним разработчиком, в GraphQL клиент решает, какие поля каждой сущности запрашивать.
Преимущества GraphQL
Общее сравнение
Дизайн
Первое преимущество, о котором следует упомянуть, - наличие только одной точки входа для нашего API. По этой причине бэкэнд-интеграция с любым клиентом проще и безопаснее. Типизированная схема для предоставления API четко определяет, что может запросить клиент, и включает политику устаревания для критических изменений. Эти функции упрощают непрерывную разработку приложения. Ключевым аспектом этого преимущества является ускорение разработки, в основном, при создании быстрых приложений, таких как CRUD API или промежуточное программное обеспечение.
Представление
Чтобы пройти по этой теме, мы можем сравнить разницу между наличием хорошо спроектированного API с конечной точкой для каждой сущности и приложением GraphQL с одной конечной точкой. Представьте себе типичный сценарий, когда вам нужно запросить набор заказов и детали их продуктов. В этом случае в REST мы выполняем два запроса: GET / orders, а затем GET / products. В GraphQL вам понадобится только один для заказов и соответствующих продуктов. Таким образом, мы сокращаем количество запросов к бэкенду и улучшаем скорость. В инфраструктуре с оплатой по факту использования (например, с функциями AWS Lambda или Azure) мы также сократим расходы на внутреннее использование.
Вы готовы к большему? Как мы уже говорили, в GraphQL мы можем запрашивать определенные поля и избегать получения ненужных. Предположим, наши продукты имеют 25 полей, смоделированных в базе данных Mongo. Нашему веб-клиенту нам нужно только показать название продукта, изображение и цену. Однако в той же модели мы храним другие поля, такие как описание, категория, бренд, размер и т. Д. Как я уже сказал в заголовке, это похоже на чтение меню и заказ только того, что вам нравится (в данном случае, то, что вам нужно).
Сообщество
GraphQL используют такие крупные компании, как Airbnb, Twitter, Github и многие другие. Создаются и поддерживаются новые инструменты, которые делают GraphQL более удобным в обслуживании, и его сообщество все больше растет. Здесь мы можем увидеть участие Stack Overflow в вопросах:
Наш опыт работы с Graph QL
В Wolox самой большой проблемой с GraphQL было создание финтех-приложения для предоставления преимуществ кредитным картам для пользователей. У нас было три недели, и я был архитектором в небольшой команде. Мы решили использовать GraphQL, чтобы ускорить интеграцию серверной части и интерфейса. Мы разработали расширяемую модель на сервере, чтобы учесть будущие новые функции и новые типы клиентов, такие как мобильные устройства или визуализация статистики. И нам это удается успешно!
Наш вывод:
- С GraphQL наша разработка идет быстрее.
- GraphQL полезен для масштабируемых приложений с разными типами клиентов.
- Интеграция backend-frontend терпела неудачу реже, чем при интеграции Rest.
- Разработчикам нравится GraphQL! В конце концов, вся команда осталась довольна кодированием на фреймворках GraphQL (мы использовали NodeJS с Apollo server для бэкэнда и React с Apollo Client). Таким образом, мы решили обучить бэкэнд-команду Wolox NodeJS работе с GraphQL с помощью митапа.
Я настоятельно рекомендую вам попробовать GraphQL в новом проекте, завершить старую службу с проблемами производительности или обновить ту, которую ваша команда не любит поддерживать. Рекомендация повара кухни и… Приятного аппетита!
