Downloaded 39 times
Uploaded byOntico
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые Облачные Технологии)
Документ охватывает проектирование высокопроизводительных REST API с акцентом на важность измерения производительности и устранение распространенных ошибок. Рассматриваются техники их оптимизации, включая кэширование, пагинацию, и проблемы с лишними данными, а также паттерны проектирования, которые помогают улучшить скорость и эффективность взаимодействия интерфейса и сервера. Итоговая рекомендация заключается в проектировании API с учетом всех аспектов пользовательского интерфейса для достижения максимальной производительности и минимизации затрат на запросы.
More Related Content
Similar to Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые Облачные Технологии)
![Тестирование API дизайна [NoBugs WTF PRO уровень]](https://cdn.slidesharecdn.com/ss_thumbnails/api-240916193321-d06a7fff-thumbnail.jpg?width=640&height=640&fit=bounds)
Дизайн REST API для высокопроизводительных систем / Александр Лебедев (Новые Облачные Технологии)
- 1. Дизайн REST APIдля высокопроизводительных систем Александр Лебедев Новые Облачные Технологии
- 2. О чем этотрассказ • Взгляд фронтенд-разработчика • С каким REST API удобно писать быстрые приложения • И какой API мешает это делать
- 3. Почему это важно •Performance • Скорость разработки
- 4.
- 5. Система с высотыптичьего полета
- 6. Люди с высотыптичьего полета
- 7. Общий подход кпроизводительности • Смотрим на систему в целом • Измерение важнее оптимизации • Избегаем простых ошибок
- 8.
- 9. Как измерять производительность •Нагружаем REST API для проверки бэкенда • Нагружаем UI для проверки фронтенда
- 10. Условия измерения производительности Картина,максимально приближенная к жизни • Данные • Количество пользователей • Сценарии использования
- 11. Измеряем производительность бэкенда дешевои сердито • Перекладываем use cases в список REST-запросов • Выполняем через JMeter • Profilt!
- 12. Измеряем производительность веб- фронтендадешево и сердито • console.time() / console.timeEnd() • window.performance.now() • Selenium для автоматизации
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. Pagination • Дешево исердито • Но есть проблемы
- 21. Pagination — подсчётрезультатов Пример стоимости получения • Данные для 20 элементов: 0.12 с • “результаты 1..20 из 1024”: 0.45 с
- 22. Pagination и Usability •Когда вы последний раз ходили на вторую страницу Гугла?
- 23. Pagination и синхронизация •А что, если список поменяется между запросами страниц?
- 24. Pagination — сухойостаток • Иногда уместно • Часто есть UI/UX-решения получше • Думайте о производительности • Думайте о кэшировании
- 25.
- 26. Проблема N+1 • RESTAPI здорового человека: 1 запрос
- 27. Проблема N+1 • RESTAPI здорового человека: 1 запрос • REST API курильщика: 11 запросов (N+1)
- 28. Проблема N+1 —причины и решения Причины • Проектирование API без мыслей об UI • Проектирование UI без мыслей об API Решения • Включать все данные в один запрос • Убрать из списка то, что нельзя получить сразу
- 29.
- 30. Лишние данные • Используется:20Kb • Загружено: 400Kb
- 31. Лишние данные —возможные решения • Краткая и полная версии объектов в API • Клиент указывает в запросе, какие данные нужны
- 32.
- 33. Кэширование • Сервер (зарамками доклада) • HTTP • Клиент
- 34. HTTP-кэш — плюсыи минусы • Общепринятый стандарт • Уже готово на сервере и на клиенте • Не кастомизируется программно • Инвалидация — обязательный поход по сети
- 35. HTTP-кэш — чтообязан знать разработчик • Cache-control, Expires • Conditional GET • Cache busting • Стабильные id
- 36. Клиентский кэш —плюсы и минусы • Максимально гибко и быстро • Но надо писать код • И придумывать решения • Дублирование логики на всех клиентах
- 37. Клиентский кэш —как делать • _.memoize() • Кэширующий REST client • Самодельный программный кэш • In-memory DB
- 38. Клиентский кэш —как делать • _.memoize() — да • Кэширующий REST client • Самодельный программный кэш • In-memory DB
- 39. Клиентский кэш —как делать • _.memoize() — да • Кэширующий REST client — нет • Самодельный программный кэш • In-memory DB
- 40. Клиентский кэш —как делать • _.memoize() — да • Кэширующий REST client — нет • Самодельный программный кэш — да • In-memory DB
- 41. Клиентский кэш —как делать • _.memoize() — да • Кэширующий REST client — нет • Самодельный программный кэш — да • In-memory DB — да
- 42. Клиентский кэш —как инвалидировать • Таймауты • События в интерфейсе • Уведомления с сервера
- 43. Клиентский кэш —как инвалидировать • Таймауты • События в интерфейсе • Уведомления с сервера Источник истины только на сервере!
- 44.
- 45. Что еще мешаетписать быстрый фронтенд • Зависимость запросов друг от друга • Не-JSON данные • Нарушение семантики HTTP • Разные ответы на один запрос • Изменение данных через GET • Изменение URL стабильных данных
- 46.
- 47. Резюме • Проектируем RESTAPI вместе и для всех • Измерение скорости важнее оптимизации • Не скрываем стоимость операций • Отталкиваемся от структуры UI • Кэшируем правильно • Не совершаем простых ошибок
- 48.
- 49.