Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!07.02.2023
Як оптимізація по стеку гуляла
Розповідь про те, як оптимізація по стеку гуляла. Ця історія почалась три тижні тому. Задача стояла покращити швидкодію API (макро)сервісу, тож в таких межах вона й була вирішена. API дійсно став швидше. Про це в минулому пості.
Але, проблеми не закінчились. Проблема раз — метрики швидкодії API стали зіпсовані, бо кожний виклик, де прибраний зайвий запит до бази, зсував середній час виконання вниз. Це не відображало справжнього стану: того, що є такі виклики, які тепер повертають миттєво без запиту, та інші виклики, які тривають так само довго, як і раніше. Проблема два — зайві запити все одно зайві.
Тому пішов далі. Хотів перенести оптимізацію до сервера, що споживає цей API. Це було б досить очевидно. Але якщо відстежити шлях виклику ще далі, то первинне джерело виклику — фронтенд. Тож логічно, що треба припинити запити ще на фронтенді. Ну добре, тут теж можна передати прапорець наявності даних, а потім пропускати виклик, якщо прапорець відсутній. На жаль, просто це зробити не вийшло, оскільки пропущений виклик залишався навічно в стані “Завантаження”. Одне з рішень — можна було б не пропускати, а імітувати виклик.
Проте я вирішив дивитися далі. Чому фронтенд взагалі робить оті виклики, у ситуації, коли акаунт ще не пройшов налаштування? Я подивився на сторінки та зрозумів, що у них відсутній стан порожнього аркуша. Новим користувачам не потрібні сторінки з результатами порожніх викликів. Тож остаточним рішенням оптимізації була реалізація порожнього стану, для якого не потрібно ніяких запитів. Так я не тільки уникнув зайвих викликів, що проходять через декілька сервісів, але й покращив досвід користувачів — як за зручністю, так і за швидкодією.
Зазначу, що таку роботу суттєво спрощує побудова команди з full-stack спеціалістів, тобто саме таких, що володіють контекстом на всіх рівнях. Якби за кожний шар відповідала окрема команда, то системні перетворення були б питанням не кількох годин, а кількох спринтів.