Всегда ли следует оптимизировать запросы Microsoft Graph?
Иногда вы можете повысить производительность своего приложения, не оптимизируя запросы Microsoft Graph. Вот почему.
Только лучший пользовательский опыт
При создании приложений мы всегда ищем способы улучшить взаимодействие с нашими пользователями. Мы хотим, чтобы наши приложения работали молниеносно. И поэтому мы оптимизируем наши ресурсы, размещаем их на CDN, удаляем ненужные метаданные и загружаем только те данные, которые нам нужны. Имеет смысл, не так ли? Чем меньше данных мы запрашиваем, тем быстрее мы можем их получить и тем быстрее мы можем показать их нашему приложению, верно? Ну да и нет.
Глядя только на запросы, имеет смысл просто загружать данные, которые вам нужны, когда они вам нужны. Ведь запрос меньшего набора данных будет быстрее. Но что, если вы посмотрите на приложение в целом?
Учитывайте общую картину при оптимизации запросов
Скажем, вы создаете приложение, которое показывает некоторую информацию о текущем пользователе. В одном месте приложения вы показываете их отображаемое имя и должность. В другом месте вы показываете своих коллег.
Чтобы получить информацию о текущем пользователе, вы вызываете конечную точку Microsoft Graph /me. Следуя идее оптимизации производительности путем простого получения необходимых данных, вы запрашиваете только те свойства, которые вам нужны: /me?$select=displayName,jobTitle.
Далее, чтобы получить список коллег, вы вызываете Microsoft Graph, чтобы получить менеджера текущего пользователя, его отчеты, а также идентификатор текущего пользователя, чтобы исключить его из списка отчетов менеджера и показать список коллег. Поскольку изначально вы получили только displayName и jobTitle текущего пользователя, вам нужно снова вызвать конечную точку /me, чтобы получить идентификатор пользователя. И именно в этом проблема: поскольку вы оптимизировали исходный запрос, теперь вам нужно выполнить два запроса вместо одного. Два запроса к Microsoft Graph редко, если вообще когда-либо, будут быстрее, чем один. Так много для лучшей производительности.
Оптимизация приложений для повышения производительности — это искусство, и чтобы сделать это правильно, вам нужно взглянуть на свое приложение с разных сторон, принимая во внимание множество переменных. Вы также должны смотреть на свое приложение в целом. Иногда получение большего количества информации, чем вам нужно, может быть быстрее, чем просто получение того, что вам нужно, когда вам это нужно в нескольких запросах. В зависимости от того, как вы создаете свое приложение, расширяя свои запросы, вы можете улучшить производительность своего приложения!
Что делать, если вы используете набор инструментов Microsoft Graph
Использование Microsoft Graph Toolkit — это самый простой способ подключить ваше приложение к Microsoft 365. Наряду с поставщиками аутентификации и компонентами, которые помогают вам подключить ваше приложение к Microsoft 365 и отображать данные из Microsoft 365, набор инструментов реализует кэширование, которое поможет вам улучшить производительность вашего приложения.
Рассмотрим сценарий, о котором я упоминал ранее при работе с Microsoft Graph Toolkit. Когда вы используете Получить компонент с включенным кэшированием, инструментарий кэширует полученные данные, используя URL-адрес запроса в качестве ключа кэша. Используя два разных оптимизированных URL-адреса, инструментарий будет выдавать два запроса и кэшировать данные под двумя отдельными ключами:
<!-- request #1 -->
<mgt-get resource="/me?$select=displayName,jobTitle" cache-enabled="true">
<template>
{{this.displayName}} ({{this.jobTitle}})
</template>
</mgt-get>
...
<!-- request #2 -->
<mgt-get resource="/me?$select=id" cache-enabled="true">
<template>
{{this.id}}
</template>
</mgt-get>Если вы расширите запрос, чтобы получить больше данных, чем требуется, набору инструментов потребуется только один запрос к Microsoft Graph. Второй компонент Get получит данные из кеша, потому что у него тот же URL:
<!-- request #1 -->
<mgt-get resource="/me?$select=displayName,jobTitle,id" cache-enabled="true">
<template>
{{this.displayName}} ({{this.jobTitle}})
</template>
</mgt-get>
...
<!-- request #1 (from cache) -->
<mgt-get resource="/me?$select=displayName,jobTitle,id" cache-enabled="true">
<template>
{{this.id}}
</template>
</mgt-get>Есть только одна вещь. Однако в зависимости от того, как построено ваше приложение, несмотря на использование одного и того же URL-адреса, вы можете увидеть, что ваше приложение выдает два точных запроса Graph. Почему? Разве мы только что не пришли к выводу, что, используя те же URL-адреса, мы должны получать данные из кеша для последующих запросов?
Все это связано со временем. Microsoft Graph Toolkit не управляет своими запросами централизованно. Каждый компонент выдает свои запросы. Если необходимые данные недоступны в кеше, он вызовет Microsoft Graph. Если два компонента Get находятся рядом друг с другом, а второй компонент загружается до того, как первый запрос будет разрешен и обработан, он вызовет Graph вместо ожидания ответа от другого компонента Get. То же самое относится и к любому другому компоненту инструментария. Если данные были ранее извлечены и кэшированы, они будут загружены из кеша без вызова Graph, но один компонент не будет ждать другого.
Резюме
Оптимизация производительности вашего приложения не является бинарной. Иногда то, что на первый взгляд кажется нелогичным, может дать лучшие результаты. Если вы хотите предложить своим пользователям лучший опыт, посмотрите на свое приложение в целом. Подумайте о том, как приложение будет использоваться и какие данные ему потребуются в любой момент. И только потом начинайте думать об оптимизации и кешировании. Так вы добьетесь наилучших результатов.
Фото автора Marc-Olivier Jodoin на Unsplash
📣 Подпишитесь на мою рассылку
Понравилась эта статья? Подпишитесь на мою рассылку новостей и получайте больше советов и рекомендаций из области, доставленных прямо на ваш почтовый ящик.
Первоначально опубликовано на https://blog.mastykarz.nl 19 июля 2021 г.
