Как GraphQL потенциально революционизирует парадигмы проектирования и разработки API.
Испытывая взлеты и падения в моем путешествии по веб-разработке, мне удалось наткнуться на сундук с сокровищами: GraphQL. Этот язык запросов API, разработанный Facebook, который обычно называют «будущим API» и «новым стандартом», очаровал меня. Мне было любопытно, как GraphQL потенциально может революционизировать парадигмы проектирования и разработки API, и после разработки симулятора инвестиций в криптовалюту с использованием фреймворка GraphQL я курировал несколько моментов обучения, на которых я остановлюсь ниже.
Краткая история дизайна и архитектуры API
Задолго до GraphQL наиболее распространенными подходами к передаче пакетов данных между веб-приложениями были SOAP (простой протокол доступа к объектам) и REST (передача репрезентативного состояния).
В то время как REST — это просто набор принципов, SOAP — это открытый стандартный протокол, поддерживаемый консорциумом World Wide Web (W3C). SOAP использует схему XML, что позволяет стандартизировать операции CRUD (создание, чтение, обновление, удаление) для разных языков и платформ устройств.
И хотя SOAP, будучи протоколом, предотвращает необходимость использования HTTP, протокол налагает стандарты, которые увеличивают сложность и, в конечном итоге, время загрузки, делая SOAP в целом медленнее. Однако эти стандарты также включают дополнительную безопасность, атомарность, согласованность, изоляцию и надежность (ACID), создавая встроенные функции обработки ошибок, а также обеспечивая безопасные транзакции базы данных.
REST, с другой стороны, представляет собой набор архитектурных принципов, использующих стандартные методы HTTP, такие как GET, POST, PUT, DELETE, для выполнения операций CRUD. И без необходимых функций безопасности протокола это оставляет структурный дизайн более открытым для дизайнера, например формат, в котором возвращаются данные (JSON, XML, обычный текст), что в конечном итоге позволяет RESTful API быть более гибкими и проще создать.
Как насчет GraphQL?
GraphQL — это спецификация, то есть она не зависит от языка. Клиент GraphQL, написанный на .NET/C#, может взаимодействовать с сервером GraphQL, написанным на Node.js, при этом используя метод HTTP POST.
Как следует из названия, GraphQL представляет свои данные в виде графа, используя узлы и ребра, а не строки и столбцы, как MongoDB. Эти узлы и ребра могут быть многомерными, что позволяет GraphQL понимать их сложность.
Возможно, самая большая разница между RESTful API и API на основе GraphQL заключается в том, что архитектура GraphQL больше ориентирована на клиента, чем архитектура RESTful на сервер. Например, если в базе данных хранятся разные типы автомобилей, и клиенту нужно название автомобиля, а также дата производства, REST должен будет либо иметь операцию GET специально для имени и даты, либо на стороне клиента пришлось бы фильтровать все посторонние данные, возвращенные в большой операции GET, чтобы найти имя и дату. Однако GraphQL позволяет клиенту указать, что ему нужны только имя и дата, чтобы не было избыточной или недостаточной выборки.
Кроме того, еще одно преимущество GraphQL заключается в том, что обмен данными происходит только в одной конечной точке, а не в нескольких конечных точках, которые нужны REST. GraphQL использует определения типов и распознаватели, чтобы указать, какие данные можно извлекать и обновлять, что позволяет клиенту использовать только один вызов API для обмена всеми необходимыми данными. Это может быть не только более эффективным во время выполнения, но и программирование этих распознавателей также позволяет использовать более сжатый код. Но поскольку все происходит в одной конечной точке, кэширование намного сложнее по сравнению с многогранными маршрутами REST.
Одно интересное замечание заключается в том, что GraphQL предлагает небольшую площадку для тестирования функциональности API, что делает программное обеспечение, такое как Insomnia и другие порталы API, устаревшими. Почти как IDE, игровая площадка позволяет разработчикам быстро тестировать новые запросы и мутации, обеспечивая более эффективное и приятное программирование.
Мои заключительные мысли
По мере того, как я создавал все больше и больше проектов с использованием GraphQL, я быстро осознал чрезвычайно крутую кривую обучения по сравнению с RESTful API. Хотя я узнал, что, хотя GraphQL предлагает многообещающие и инновационные решения, которые потенциально могут сэкономить много времени, безусловно, бывают случаи, когда я хотел бы использовать RESTful API вместо GraphQL. Например, если бы мне нужно было сделать общедоступный API, я бы хотел иметь строгий контроль над тем, какие данные публикуются. В будущем я определенно мог бы видеть GraphQL в качестве основного языка запросов, но он определенно не решает всех проблем, связанных с API, и не может заменить REST.
Больше контента на plainenglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Получите эксклюзивный доступ к возможностям написания и советам в нашем сообществе Discord.
