Зачем кэшировать запросы GraphQL?

Недавнее исследование Google пришло к выводу, что увеличение времени отклика страницы на 400 мс приводит к снижению трафика на 0,44%. Таким образом, задержка на странице Google в 400 мс приводит к 440 миллионам прерванных сеансов в месяц, что приводит к невероятной потере дохода от рекламы для сайта и потенциальных продаж товаров и услуг. По данным Google на февраль 2018 года, 53% посетителей покидают страницу, если загрузка занимает более трех секунд. Нейронная сеть, обученная предсказывать поведение пользователя с точностью 90%, показала, что по мере того, как время загрузки страницы увеличивается от 1 до 10 секунд, вероятность отскока посетителя сайта возрастает до ошеломляющих 123%. Короче говоря: если строить медленно, они уходят.

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

Варианты кеширования с помощью GraphQL

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

Такие библиотеки, как Apollo и Relay, наиболее широко реализованы для спецификации GraphQL и предлагают огромный набор функций. Apollo - это полнофункциональная библиотека для приложений GraphQL, предоставляющая инструменты и библиотеки во всем стеке. Apollo предлагает возможность преобразовать существующую архитектуру RESTful в экземпляр GraphQL, обернув ваши конечные точки, предоставляя пользователям отзывчивый механизм кэширования для серверов GraphQL и предлагая инструменты для взаимодействия с клиентской стороной. Однако для пользовательских приложений, взаимодействующих с существующими серверными модулями GraphQL, вес и проблемы, неявные при реализации этих более крупных библиотек, могут быть нежелательными.

Альтернативы более крупным библиотекам

FlacheQL - это недавно разработанная альтернатива этим более крупным библиотекам с открытым исходным кодом для кэширования клиента. Его преимущество в том, что он легкий и невероятно простой в настройке и интеграции в ваше приложение. Простая реализация FlacheQL использует локальное хранилище клиента, чтобы обеспечить молниеносное извлечение для кэшированных запросов, обычно на 150% быстрее, чем у Apollo.

FlacheQL также имеет явное преимущество, заключающееся в возможности возвращать подмножества кэшированных ответов по параметрам поиска, чего не предлагает никакой другой механизм кэширования. Это означает, что если вы ищете репозитории Github с тегами React и 1000 звездочек, а затем отправляете запрос с теми же параметрами, но с 3000 звездами, FlacheQL немедленно вернет результаты из кеша, в то время как библиотеки, такие как Apollo и Relay, должны будут совершить еще одно путешествие в базу данных. Эта функция обеспечивается расширенным алгоритмом сравнения, который устанавливает эквивалентность среди подмножеств запросов. После того, как разработчик определит схему подмножеств данных, которые они ожидают в своем приложении, FlacheQL будет интерпретировать запросы, чтобы возвращать соответствующие данные на основе типов подмножеств, определенных параметрами поиска.

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

Выбор правильной библиотеки

Одним из наиболее важных элементов, которые следует учитывать при выборе библиотеки кэширования, является тип кэширования, который будет удовлетворять потребности вашего приложения. Запросы GraphQL часто состоят из параметров и полей поиска. FlacheQL был разработан, чтобы предлагать оба типа кеширования. Вот несколько примеров запросов, которые попадают в Yelp API:

Если вы имеете дело с большим приложением, которому требуется только частичное извлечение по полям запроса, Apollo или Relay могут интегрироваться с Redux, например, чтобы использовать их кеши в качестве единственного источника достоверной информации в вашем приложении. Однако, если вы имеете дело с небольшим приложением, где скорость является центральной проблемой и где необходимо кэширование обоих полей параметров и (или только параметров), FlacheQL может быть лучшим вариантом.

Как инженеры-программисты, мы внедряем кеширование, чтобы повысить производительность наших приложений и снизить нагрузку на наши серверы. Кеши есть везде: от базы данных до прокси-сервера и до клиента. Когда мы начинаем рассматривать UX наших приложений, эти принципы и практики становятся особенно актуальными. Выбор правильной библиотеки кэширования для GraphQL поможет вам разрабатывать более производительные приложения, с минимальным отказом от страниц.

Для получения дополнительной информации и взаимодействия с демонстрацией возможностей FlacheQL посетите www.flacheql.io, проверьте репозиторий GitHub и отметьте его звездочкой, а также поэкспериментируйте с ним в своих пользовательских приложениях!

Подробнее откуда это взялось

Эта история публикуется в журнале Noteworthy, куда ежедневно приходят тысячи людей, чтобы узнать о людях и идеях, формирующих наши любимые продукты.

Следите за нашей публикацией, чтобы увидеть больше историй о продуктах и ​​дизайне, представленных командой Journal.