УДК 004.6
Полонский Василий Александрович – студент Ростовского государственного экономического университета (РИНХ).
Аннотация: В данной научной статье рассмотрены актуальные способы обмена информации между сервером и мобильным приложением. В статье проведен сравнительный анализ преимуществ и недостатков GraphQL и REST API, которые применяются для разработки клиент-серверного приложения. Показана значимость проведения исследования. Выделены основные проблемы, которые могут быть получены при работе с GraphQL, и способы их решения.
Ключевые слова: мобильное приложение, футбольные команды, средства разработки, футболисты, тренер.
Разработка клиент-серверного приложения может вызвать множество проблем из-за ограничений современных мобильных устройств. Часто возникает вопрос о том, какой способ обмена информацией между сервером и мобильным приложением может быть более надежным. Для пользователей важно иметь приложение, которое действительно работает быстро и желательно без ошибок. GraphQL предоставляет набор данных в API, который легко может применяться без избыточных запросов. GraphQL упрощает развитие API с течением времени. GraphQL также можно использовать для создания крупных инструментов разработчика.
В последнее десятилетие REST был основным стандартом для разработки API. Инструмент предлагает возможности создания серверов без сохранения состояния, структурированный доступ к ресурсам [1].
В настоящее время, REST часто вызывает споры относительно его применения. Требования клиента к данным меняются очень быстро, а REST API недостаточно гибок. Он зачастую не успевает за изменениями в требованиях клиента. Возможно, чтобы удовлетворить этот спрос на гибкость и высокую эффективность и появился GraphQL. Он устраняет многие недостатки и проблемы, возникающие при взаимодействии с REST API.
В обычных условиях, когда вызываем общий интерфейс API, клиент зачастую получает больше информации, чем действительно требуется приложению. Например, пользовательский интерфейс должен отображать список пользователей, при использовании REST API обычно вызывается конечная точка, которая получает массив JSON с пользовательскими данными, эти данные одинаковы для всех клиентов API, тогда как мобильному приложению нужны только имена пользователя, планшету нужен немного больший набор данных и полный набор данных нужен в лучшем случае только веб приложению.
GraphQL решает эту проблему, он позволяет предоставлять только запрошенные конкретным клиентом данные. Это отчасти упрощается тем, что GraphQL является самодокументируемым API, так как в схеме отражены все возможные запросы, параметры и их типа. Требование по строгой типизации данных позволяет существенно уменьшить количество ошибок связи между клиентом и сервером. Также GraphQL содержит функцию самопроверки перед отправки результата, как с серверной, так и клиентской стороны. В GraphQL так же есть средства по оптимизации и кешированию запросов к API, при этом позволяется использовать имеющиеся базовые директивы и определять собственные.
Важно при этом понимать что, GraphQL не определяет конкретную архитектуру приложения, он может использовать в качестве источника данных не только базы данных, микросервисы, но и существующие REST API
Одна из наиболее распространенных проблем с REST – это чрезмерная или недостаточная выборка. Это происходит потому, что единственный способ для клиента загрузить данные – это запросить данные в конечных точках, которые возвращают фиксированные структуры данных. Очень сложно спроектировать API таким образом, чтобы он мог предоставлять клиентам только те данные, которые нужны клиенту. Избыточная выборка означает, что клиент загружает больше информации, чем фактически требуется в приложении.
Использование GraphQL как языка запросов к API требует определенных навыков от программиста, поэтому даже разработчик, знакомый с REST API, должен потратить некоторое время, чтобы освоить GraphQL. В зависимости от реализации GraphQL может потребоваться включение стратегии управления API, отличной от REST API, подбор стратегии должен осуществляться с учетом ограничения скорости обработки запросов. Также механизм кеширования устроен сложнее, чем в REST API, поскольку браузер сохраняет кеш только запросы с методом GET, тогда как в GraphQL используется только метод POST. В этом случае задачу кеширования разрешает программист вручную для каждого запроса. Еще одной проблемой является перенос проблем n + 1 запроса с клиенткой части на серверную, для частичного решения этой проблемы были разработаны библиотеки пакетного импорта и экспорта данных из базы данных [2].
При использовании REST можно построить систему мониторинга на основе кодов ответов API. В GraphQL этого нет, потому что он всегда возвращает 200 OK статусный ответ, из-за этого в GraphQL намного сложнее обрабатывать и отслеживать различные сценарии ошибок.
Подводя итоги, можно сказать, что GraphQL не заменяет REST, а является альтернативой, обеспечивающей быструю среду разработки с декларативным и гибким характером, предлагает множество улучшений по сравнению с REST. GraphQL уже реализован на нескольких популярных языках, таких как JavaScript, Go и Java.
Список литературы