З розвитком проєктів і збільшенням кількості сторінок, управління запитами до бекенду для приладної панелі MobileAction стало все більш складним. Наш поточний кастомізований підхід більше не відповідає вимогам наших проєктів.
Спочатку ми використовували просту та гнучку структуру для задоволення потреб користувачів приладної панелі. Однак з часом збільшення кількості сторінок та різноманіття взаємодій користувачів зробило управління запитами даних все більш складним. Наш кастомізований підхід ускладнювався з кожною новою сторінкою та додаванням нових функцій, що призводило до зростання витрат на обслуговування та уповільнення процесу розробки. Це не тільки знижувало нашу ефективність, але й впливало на якість досвіду, який ми надаємо кінцевим користувачам.
Стикнувшись із цими проблемами, ми почали шукати більш сучасне та ефективне рішення. Під час досліджень ми зрозуміли, що можливості, які надає TanStack Query, ідеально підходять для потреб наших проєктів. Переваги, такі як автоматичне кешування даних, управління запитами та оптимізація продуктивності, що надаються TanStack Query, зробили його ідеальним вибором для вирішення наших наявних проблем. У цій статті я детально розповім про проблеми, які ми зустріли з нашим поточним підходом, процес переходу на TanStack Query та отримані переваги.
Розуміння поточної структури
MaRequestPooler та MaRequestCache
Перед відображенням даних користувачам, нам часто потрібно було об'єднати кілька різних запитів до бекенду. Для того, щоб отримати певні дані швидше, ми використовували власний механізм кешування, розроблений спеціально для цього проєкту. Цю настройку можна пояснити через три основні компоненти:
MaRequestPooler:
- В основі цього компонента лежить структура управління запитами, побудована на бібліотеці Axios.
- Вона працює за логікою черги запитів і обробляє їх по черзі.
- Якщо запит не вдається, він знову додається до черги для повторної спроби.
MaRequestCache:
- Вона намагається запобігти повторному отриманню однакових даних, кешуючи певні GET запити на основі URL.
- Однак кешування здійснюється тільки на рівні URL; зміни в порядку чи форматі параметрів можуть вимагати додаткових налаштувань.
Функції makeRequest та cacheRequest:
- makeRequest: Використовується для надсилання запитів без кешування.
- cacheRequest: Забезпечує функціональність кешування тільки GET запитів, здебільшого на основі URL запиту.
Отже, як створюється запит до бекенду? Давайте ближче поглянемо на функцію makeRequest.
function makeRequest(url, axiosConfig = {}, poolerOpts = {}) {...}
Тут:
- url: представляє URL сервера.
- axiosConfig: налаштування, які ми хочемо кастомізувати для Axios.
- poolerOpts: додаткові налаштування для пулера запитів, такі як кешування запиту.
Простий приклад: fetchKeywordStats
function fetchKeywordStats({ keyword, countryCode, startDate, endDate }) {
return makeRequest(
`keyword/stats/${countryCode}?${paramsToQuery({ startDate,endDate })}`,
{
method: 'POST',
data: {
keyword,
},
}
);
}
У наведеному прикладі, функція fetchKeywordStats отримує статистику для конкретного ключового слова. Функція makeRequest створює запит за допомогою методу POST і надсилає необхідні дані (ключове слово) на сервер.
З розвитком проєктів і зростанням кількості сторінок, управління запитами до бекенду для приладної панелі MobileAction стало все більш складним. Наш поточний кастомізований підхід більше не задовольняє вимогам наших проєктів.
Спочатку ми використовували просту і гнучку структуру для задоволення потреб користувачів на панелі керування. Проте з часом, через збільшення кількості сторінок та різноманітність взаємодій з користувачами, управління запитами даних стало дедалі складнішим. Наш кастомізований підхід з кожним новим додаванням сторінок та функцій приносив додаткову складність, що збільшувало витрати на обслуговування і сповільнювало процес розробки. Це не лише знижувало нашу ефективність, але й впливало на якість досвіду, який ми надавали кінцевим користувачам.
Стикнувшись із цими проблемами, ми почали шукати більш сучасне та ефективне рішення. Під час досліджень ми зрозуміли, що можливості, які надає TanStack Query, ідеально підходять для потреб наших проєктів. Переваги, такі як автоматичне кешування даних, управління запитами та оптимізація продуктивності, надані TanStack Query, зробили його ідеальним вибором для вирішення наших наявних проблем. У цій статті я детально розповім про проблеми, які ми зустріли з нашим поточним підходом, процес переходу на TanStack Query і переваги, які ми здобули.
Розуміння поточної структури
MaRequestPooler та MaRequestCache
Перед відображенням даних користувачам, нам часто потрібно було поєднати кілька різних запитів до бекенду. Для того, щоб отримати певні дані швидше, ми використовували власний механізм кешування, розроблений спеціально для цього проєкту. Цю структуру можна пояснити через три основні компоненти:
MaRequestPooler:
- В основі цієї структури лежить управління запитами, побудоване на бібліотеці Axios.
- Воно працює за принципом черги запитів і обробляє їх по черзі.
- Якщо запит не вдається, він знову додається до черги для повторної спроби.
MaRequestCache:
- Цей компонент намагається запобігти повторному отриманню однакових даних, кешуючи певні GET запити на основі URL.
- Проте кешування здійснюється лише на рівні URL, тому зміни в порядку чи форматі параметрів можуть потребувати додаткових налаштувань.
Функції makeRequest та cacheRequest:
- makeRequest: Використовується для надсилання запитів без кешування.
- cacheRequest: Забезпечує функціональність кешування тільки GET запитів, здебільшого на основі URL запиту.
Отже, як створюється запит до бекенду? Давайте детальніше розглянемо функцію makeRequest.
function makeRequest(url, axiosConfig = {}, poolerOpts = {}) {...}
Тут:
- url: представляє URL сервера.
- axiosConfig: налаштування, які ми хочемо кастомізувати для Axios.
- poolerOpts: додаткові налаштування для пулера запитів, такі як кешування запиту.
Простий приклад: fetchKeywordStats
function fetchKeywordStats({ keyword, countryCode, startDate, endDate }) {
return makeRequest(
`keyword/stats/${countryCode}?${paramsToQuery({ startDate,endDate })}`,
{
method: 'POST',
data: {
keyword,
},
}
);
}
У наведеному прикладі, функція fetchKeywordStats отримує статистику для конкретного ключового слова. Функція makeRequest створює запит за допомогою методу POST та надсилає необхідні дані (ключове слово) на сервер.
Хоча цей метод був простим і функціональним на початку, з ростом масштабу проєкту нам довелося додавати нові сценарії.
Використання в компоненті Vue
Наприклад, припустимо, ми хочемо відобразити статистику за ключовими словами для користувача в компоненті Vue:
Цей приклад потребує написання кількох рядків коду навіть для самого простого сценарію щасливого шляху. Крім того, коли ми додаємо детальні блоки керування такими аспектами, як скасування запиту, запобігання дублюванню запитів, термін придатності кешу або навіть різні рівні обробки помилок, код стає ще складнішим.
Зростання складності
- Скасування запитів
Коли користувач швидко робить нові запити з різними параметрами, може виникнути необхідність скасувати попередній запит. Для цього додаванняcancelTokenабо кастомних функцій знижує читаність коду в компоненті. - Запобігання дублюванню запитів
Якщо кілька запитів надсилаються до одного й того ж кінцевого пункту з тими ж параметрами, ми можемо захотіти заблокувати або скасувати нові запити. Управління цим вимагає створення додаткових механізмів контролю, таких як концепціяfetchKey. - Різні сценарії
— Обробка масових операцій, коли необхідно виконати кілька запитів,
— Управління даними в інтерфейсах, таких як пагінація та необмежене прокручування,
— Призначення різних пріоритетів для сценаріїв анулювання кешу,
Теми, подібні до цих, змушують нас додавати нові елементи до системи з кожним новим сценарієм.
Хоча цей метод був простим і функціональним на початку, з ростом масштабу проєкту нам довелося додавати нові сценарії.
Використання в компоненті Vue
Наприклад, припустимо, ми хочемо відобразити статистику за ключовими словами для користувача в компоненті Vue:
Цей приклад потребує написання кількох рядків коду навіть для самого простого сценарію щасливого шляху. Крім того, коли ми додаємо детальні блоки керування такими аспектами, як скасування запиту, запобігання дублюванню запитів, термін придатності кешу або навіть різні рівні обробки помилок, код стає ще складнішим.
Зростання складності
- Скасування запитів
Коли користувач швидко робить нові запити з різними параметрами, може виникнути необхідність скасувати попередній запит. Для цього додаванняcancelTokenабо кастомних функцій знижує читаність коду в компоненті. - Запобігання дублюванню запитів
Якщо кілька запитів надсилаються до одного й того ж кінцевого пункту з тими ж параметрами, ми можемо захотіти заблокувати або скасувати нові запити. Управління цим вимагає створення додаткових механізмів контролю, таких як концепціяfetchKey. - Різні сценарії
— Обробка масових операцій, коли необхідно виконати кілька запитів,
— Управління даними в інтерфейсах, таких як пагінація та необмежене прокручування,
— Призначення різних пріоритетів для сценаріїв анулювання кешу,
Теми, подібні до цих, змушують нас додавати нові елементи до системи з кожним новим сценарієм.
Це неминуче призводить до збільшення дублювання коду і ускладнює його обслуговування.
З огляду на контролі, які ми пишемо для обробки скасування запитів і запобігання дублювання запитів, кінцевий стан коду виглядає ось так:
Навіть вирішення лише двох проблем з поточною налаштуванням вимагало написання значної кількості коду, і ми ще не включили частину, пов’язану з відображенням даних.
З цих причин ми вирішили перейти до стандартної бібліотеки, щоб створити більш надійну основу для процесів отримання даних, кешування та керування, як для робочого процесу команди, так і для майбутнього проекту.
TanStack Query: Сучасне рішення
Наше дослідження показало, що TanStack Query ефективно задовольняє потреби наших проектів. Вона пропонує комплексні можливості для керування станом сервера, включаючи автоматичне кешування даних, керування запитами, оптимізацію продуктивності та скасування запитів.
Наприклад, коли ми хочемо отримати ті ж самі статистичні дані за ключовим словом за допомогою TanStack Query, код, який нам потрібно написати, виглядає ось так:
Як видно, сама бібліотека обробляє різні сценарії скасування запитів, запобігання дублюванню і фонові операції кешування. Це дозволяє нам зосередитися лише на відображенні даних і простому керуванні станом.
Досягнуті вигоди
- Простота і зрозумілість коду
Без необхідності писати власні функції для скасування запитів, запобігання дублюванню або оновлення даних, наші компоненти зосереджуються тільки на тому, де і як дані отримуються. - Продуктивність і досвід користувача
Завдяки автоматичному кешуванню і фоновому повторному отриманню даних, користувачі можуть швидко отримувати доступ до даних, при цьому ми підтримуємо їх свіжість. - Легкість обслуговування та масштабованість
При інтеграції нових розробників в проект, вони можуть скористатися документацією TanStack Query, що прискорює процес і полегшує його. Крім того, бібліотека має активну спільноту та регулярні оновлення.
4.
Це неминуче призводить до збільшення дублювання коду і ускладнює його обслуговування.
З огляду на контролі, які ми пишемо для обробки скасування запитів і запобігання дублювання запитів, кінцевий стан коду виглядає ось так:
Навіть вирішення лише двох проблем з поточною налаштуванням вимагало написання значної кількості коду, і ми ще не включили частину, пов’язану з відображенням даних.
З цих причин ми вирішили перейти до стандартної бібліотеки, щоб створити більш надійну основу для процесів отримання даних, кешування та керування, як для робочого процесу команди, так і для майбутнього проекту.
TanStack Query: Сучасне рішення
Наше дослідження показало, що TanStack Query ефективно задовольняє потреби наших проектів. Вона пропонує комплексні можливості для керування станом сервера, включаючи автоматичне кешування даних, керування запитами, оптимізацію продуктивності та скасування запитів.
Наприклад, коли ми хочемо отримати ті ж самі статистичні дані за ключовим словом за допомогою TanStack Query, код, який нам потрібно написати, виглядає ось так:
Як видно, сама бібліотека обробляє різні сценарії скасування запитів, запобігання дублюванню і фонові операції кешування. Це дозволяє нам зосередитися лише на відображенні даних і простому керуванні станом.
Досягнуті вигоди
- Простота і зрозумілий код
Без необхідності писати власні функції для скасування запитів, запобігання дублюванню або оновлення даних, наші компоненти зосереджуються тільки на тому, де і як дані отримуються. - Продуктивність і досвід користувача
Завдяки автоматичному кешуванню і фоновому повторному отриманню даних, користувачі можуть швидко отримувати доступ до даних, при цьому ми підтримуємо їх свіжість. - Легкість обслуговування та масштабованість
При інтеграції нових розробників в проект, вони можуть скористатися документацією TanStack Query, що прискорює процес і полегшує його. Крім того, бібліотека має активну спільноту та регулярні оновлення.
4.
Розділення стану сервера і клієнта
За допомогою TanStack Query ми можемо зберігати і керувати даними, що стосуються сервера, безпосередньо в бібліотеці, тоді як стан клієнта (наприклад, вибір теми, тимчасові фільтри тощо) обробляється за допомогою інструментів, таких як Pinia або інших рішень для керування станом. Це чітке розмежування робить проект більш модульним.
Висновок
Зі збільшенням кількості сторінок та функціональності в проекті, управління даними стало більш складним. Наш власний підхід, який добре працював для нас протягом тривалого часу, не зміг впоратися з такими аспектами, як скасування запитів, запобігання дублюванню та управління кешем. Це змусило нас прийняти TanStack Query. Його функції, такі як автоматичне кешування, керування запитами та оптимізація продуктивності, не тільки знизили витрати на обслуговування, а й значно спростили нашу кодову базу.
Зараз ми використовуємо комбінацію нашого власного методу та TanStack Query для досягнення більш сталого і зрозумілого управління API. Досвід, який ми отримали, підвищив ефективність нашої команди і дозволив нам розширювати проект новими функціями.
Щасливого кодування!
Розділення стану сервера і клієнта
Використовуючи TanStack Query, ми можемо зберігати і керувати даними, що стосуються сервера, безпосередньо в бібліотеці, в той час як стан клієнта (наприклад, вибір теми, тимчасові фільтри тощо) обробляється за допомогою інструментів, таких як Pinia або інших рішень для керування станом. Це чітке розмежування робить проект більш модульним.
Висновок
Зі збільшенням кількості сторінок і функцій у проекті управління даними стало складнішим. Наш власний підхід, який довгий час добре виконував свої функції, не зміг впоратися з такими аспектами, як скасування запитів, запобігання дублюванню та управління кешем. Це змусило нас прийняти TanStack Query. Його функції, такі як автоматичне кешування, керування запитами та оптимізація продуктивності, не лише зменшили витрати на обслуговування, але й значно спростили нашу кодову базу.
Зараз ми використовуємо комбінацію нашого власного методу та TanStack Query для досягнення більш сталого і зрозумілого управління API. Досвід, який ми здобули, підвищив ефективність нашої команди, дозволяючи нам розширювати проект новими функціями.
Щасливого кодування!
Перекладено з: Transition to TanStack Query: A More Modern API Management