В этом видео покажу как в Posman делается нагрузочное тестирование, и с помощью него сравню скорость выполнения идентичных запросов GraphQL и REST. github.com/AlexanderZhelnin/DEMO
Сделал тоже самое с local MSSQL, REST и GraphQL в одном проекте. Данные беру из EF context в обоих случаях. Скорость одинаковая (как и должно быть). P.S. В целом видео классные, подписался.
Подскажите, а как в GraphQl лучше работать с динамическими объектами? Получить все поля, без перечисления в query как я понял нельзя? К примеру, имеется динамическая форма (сотрудника), строится на основе конфиг-файла json. С сервера приходит сам объект со всеми полями, строится форма. Почему-то решил спросить в этом ролике )
У меня проекты больше это как замена десктопным приложениям. Раньше была своя система для отчётов. Сейчас хочу поизучать этот вопрос. Проектов много, команд много, посмотрю что кто использует.
@@Kulibins1 тоже как замена десктопу начал переносить на blazor проект. Пока проблема только с передачей файла. С отчётами есть идеи, но пока ищу все варианты.
Привет! Не очень понимаю почему GraphQL оказался быстрее, ведь он работает поверх HTTP и наоборот должен только добавлять время. Было бы хорошо, если бы еще сравнили какой SQL запрос генерируется, наверное в нём всё дело?
Ну да, если с фронта одним запросом графа можно забрать все данные, нежели рестом несколькими запросами с разных эндпоинтов.. И что тогда будет быстрее?
GraphQL быстрее, но в rest тоже можно сделать специальный запрос который сможет вернуть всё, REST не ограничен CRUD, но такие запросы нужно делать каждый раз, а их может быть много, и они заранее не известны.
С мой точки зрения GraphQL личе во всем. Но rest проще и более распространен, для некоторых стыковок различных систем между собой наверное лучше использовать rest
Как посчитали 20% ? GraphQL добавляет буквально чуть-чуть, причем т.к. запросы мы группируем, то наоборот у GraphQL будет меньше данных, т.к. у каждого запроса есть еще http header и т.д. если писать под любое требование оптимизированный запрос то мы в ответе json видим дополнительно слово data и название функции, если вы включили что-то для отладки, то это не релизное сравнение, в rest мы то же можем напихать для отладки чего лишнего. Из моего опыта данные во много раз перевешивают слово data и название функции + что бы не говорили а многие не оптимизируют и в результате на rest кучу лишних запросов - GraphQL лишён этих недостатков, разработка ускоряется, запросов меньше.
@@Kulibins1 Респонс для REST: 2.5 килобайта, для GraphQL: 3 килобайта. Но может действительно в реальных условиях с более емкими запросами жила разница или пропадет или не будет так заметна. Спасибо )
@@mihailamurov8575 посмотрел, и понял почему у вас так, русские буквы в ответе превратились в \u0410\u0432\u0442\u043E\u0440 из-за этого разница в размере. Самое интересное, если поставить ResponseCompression на бэке, то сжатый ответ graphql оказался почему-то значительно меньше 2.9 kb против 8.2 у REST. Если не сжимать, то 84.5 против 61.5 kb у рест. Но у меня на рабочих проектах всегда стоит сжимать. Нужно посмотреть как настраивается сериализация для HotChocolate ( или чем вы пользуетесь )
Потому что это очередная абстракция,+ как она реализована внутри вопрос, если у вас в приложении работает , 20% это огромная потеря производительности, это будет заметно
@@user-hy8kc7ht7v я уже ответил на этот вопрос нет такого что rest легче!!! Оно одинаково по размеру ответа. Тут дело в кодировке по умолчанию русского текста. В qraphql hot chocolate тоже можно убрать перекодирование и будет так же, более в rest изначально тоже русский текст через кодировку выдавал, пришлось опцию json серелизации выставлять. Я у себе провел замеры и в ответе на вопрос их выложил. Что rest что grapql это надстройки 🤣 только graphql не медленнее и гораздо фукциональнее , на написание бэка тратится гораздо меньше времени. Конечно если цель: бесконечная работа, то qraphql это минус, а если скорость, функциональность, то это qraphql. Целую статью на Хабре писал GraphQL: как сделать бэкенд приложения экономнее и быстрее habr.com/p/593115/
Сам удивился, думал либо равны, либо REST на одинаковом результате будет быстрее, но вот результат: GraphQL в несколько раз быстрее. Может повлиял еще запрос в базу данных. Sql в горячем шоколаде, чуть от того что entity формирует отличается. Надо еще провести расширенные эксперименты. Изначально в видео хотел показать как тестить Postman, и взял пример, а оно вот как получилось.
Конечно через postman это не прям супернагрузочное тестирование, да и запрос в бд тут реально без кэширования, запрос с join получается - но факт от этого не меняется, думал что накладные расходы у GraphQL будут выше, а оказалось что он не то что не медленее , но и чуть быстрее - Суть видео была сравнить на примере.
@@Kulibins1 20 - 80 миллисекунд для запроса на локальную машину - это очень медленно для небольших запросов. Думаю, дело не в том, что используется REST.
