В этом видео покажу как в Posman делается нагрузочное тестирование, и с помощью него сравню скорость выполнения идентичных запросов GraphQL и REST. github.com/Ale...
Все дело в сериализаторах. Хорошо написанный (желательно отдельной внешней либой на С) сериализатор даст аналогичный с GraphQL результат. Однако, с этим новомодным GraphQL придется кучу логики на бэкенде делать (схемы всякие, обработкичики).
Сделал тоже самое с local MSSQL, REST и GraphQL в одном проекте. Данные беру из EF context в обоих случаях. Скорость одинаковая (как и должно быть). P.S. В целом видео классные, подписался.
Привет! Не очень понимаю почему GraphQL оказался быстрее, ведь он работает поверх HTTP и наоборот должен только добавлять время. Было бы хорошо, если бы еще сравнили какой SQL запрос генерируется, наверное в нём всё дело?
Подскажите, а как в GraphQl лучше работать с динамическими объектами? Получить все поля, без перечисления в query как я понял нельзя? К примеру, имеется динамическая форма (сотрудника), строится на основе конфиг-файла json. С сервера приходит сам объект со всеми полями, строится форма. Почему-то решил спросить в этом ролике )
Как посчитали 20% ? GraphQL добавляет буквально чуть-чуть, причем т.к. запросы мы группируем, то наоборот у GraphQL будет меньше данных, т.к. у каждого запроса есть еще http header и т.д. если писать под любое требование оптимизированный запрос то мы в ответе json видим дополнительно слово data и название функции, если вы включили что-то для отладки, то это не релизное сравнение, в rest мы то же можем напихать для отладки чего лишнего. Из моего опыта данные во много раз перевешивают слово data и название функции + что бы не говорили а многие не оптимизируют и в результате на rest кучу лишних запросов - GraphQL лишён этих недостатков, разработка ускоряется, запросов меньше.
@@Kulibins1 Респонс для REST: 2.5 килобайта, для GraphQL: 3 килобайта. Но может действительно в реальных условиях с более емкими запросами жила разница или пропадет или не будет так заметна. Спасибо )
@@mihail8575 посмотрел, и понял почему у вас так, русские буквы в ответе превратились в \u0410\u0432\u0442\u043E\u0440 из-за этого разница в размере. Самое интересное, если поставить ResponseCompression на бэке, то сжатый ответ graphql оказался почему-то значительно меньше 2.9 kb против 8.2 у REST. Если не сжимать, то 84.5 против 61.5 kb у рест. Но у меня на рабочих проектах всегда стоит сжимать. Нужно посмотреть как настраивается сериализация для HotChocolate ( или чем вы пользуетесь )
Потому что это очередная абстракция,+ как она реализована внутри вопрос, если у вас в приложении работает , 20% это огромная потеря производительности, это будет заметно
@@ИванПошековский я уже ответил на этот вопрос нет такого что rest легче!!! Оно одинаково по размеру ответа. Тут дело в кодировке по умолчанию русского текста. В qraphql hot chocolate тоже можно убрать перекодирование и будет так же, более в rest изначально тоже русский текст через кодировку выдавал, пришлось опцию json серелизации выставлять. Я у себе провел замеры и в ответе на вопрос их выложил. Что rest что grapql это надстройки 🤣 только graphql не медленнее и гораздо фукциональнее , на написание бэка тратится гораздо меньше времени. Конечно если цель: бесконечная работа, то qraphql это минус, а если скорость, функциональность, то это qraphql. Целую статью на Хабре писал GraphQL: как сделать бэкенд приложения экономнее и быстрее habr.com/p/593115/
У меня проекты больше это как замена десктопным приложениям. Раньше была своя система для отчётов. Сейчас хочу поизучать этот вопрос. Проектов много, команд много, посмотрю что кто использует.
@@Kulibins1 тоже как замена десктопу начал переносить на blazor проект. Пока проблема только с передачей файла. С отчётами есть идеи, но пока ищу все варианты.
С мой точки зрения GraphQL личе во всем. Но rest проще и более распространен, для некоторых стыковок различных систем между собой наверное лучше использовать rest
Ну да, если с фронта одним запросом графа можно забрать все данные, нежели рестом несколькими запросами с разных эндпоинтов.. И что тогда будет быстрее?
GraphQL быстрее, но в rest тоже можно сделать специальный запрос который сможет вернуть всё, REST не ограничен CRUD, но такие запросы нужно делать каждый раз, а их может быть много, и они заранее не известны.
Конечно через postman это не прям супернагрузочное тестирование, да и запрос в бд тут реально без кэширования, запрос с join получается - но факт от этого не меняется, думал что накладные расходы у GraphQL будут выше, а оказалось что он не то что не медленее , но и чуть быстрее - Суть видео была сравнить на примере.
@@Kulibins1 20 - 80 миллисекунд для запроса на локальную машину - это очень медленно для небольших запросов. Думаю, дело не в том, что используется REST.
Сам удивился, думал либо равны, либо REST на одинаковом результате будет быстрее, но вот результат: GraphQL в несколько раз быстрее. Может повлиял еще запрос в базу данных. Sql в горячем шоколаде, чуть от того что entity формирует отличается. Надо еще провести расширенные эксперименты. Изначально в видео хотел показать как тестить Postman, и взял пример, а оно вот как получилось.
Крутой чел! Интересно смотреть❤
Спасибо за видео, решил использовать Graphql, нашел понятное сравнение с REST по производительности!
В нашем полку прибыло 👍
Перепроверил REST, у меня настроен NewtonJson в качестве серилизатора, поставил стандартный, который быстрее, но это не повлияло на результат.
Все дело в сериализаторах. Хорошо написанный (желательно отдельной внешней либой на С) сериализатор даст аналогичный с GraphQL результат. Однако, с этим новомодным GraphQL придется кучу логики на бэкенде делать (схемы всякие, обработкичики).
@@evgen86n вот именно не нужно изобретать велосипед
Спасибо большое за видео, они топовые!)
Рад что нравится, у вас система тоже очень известная 👍
Спасибо. Классный ролик.
Всегда пожалуйста.
Сделал тоже самое с local MSSQL, REST и GraphQL в одном проекте. Данные беру из EF context в обоих случаях. Скорость одинаковая (как и должно быть). P.S. В целом видео классные, подписался.
Я изначально думал что скорость rest будет выше, а она как минимум одинаковая, поэтому graphql очень хорош
Привет! Не очень понимаю почему GraphQL оказался быстрее, ведь он работает поверх HTTP и наоборот должен только добавлять время. Было бы хорошо, если бы еще сравнили какой SQL запрос генерируется, наверное в нём всё дело?
По какой-то причине более оптимальный запрос, хотя и там и там entity. А так накладные расходы graphql ничтожные.
Подскажите, а как в GraphQl лучше работать с динамическими объектами? Получить все поля, без перечисления в query как я понял нельзя?
К примеру, имеется динамическая форма (сотрудника), строится на основе конфиг-файла json.
С сервера приходит сам объект со всеми полями, строится форма.
Почему-то решил спросить в этом ролике )
Тут может помочь хранение в виде json, когда у вас поле json строка. И при получении её происходит десирелизация
Почему с REST возвращаются данные на 20% "легче" чем с GraphQL?
Может ли это сказаться при большем объеме данных и реальных условиях по сети?
Как посчитали 20% ? GraphQL добавляет буквально чуть-чуть, причем т.к. запросы мы группируем, то наоборот у GraphQL будет меньше данных, т.к. у каждого запроса есть еще http header и т.д. если писать под любое требование оптимизированный запрос то мы в ответе json видим дополнительно слово data и название функции, если вы включили что-то для отладки, то это не релизное сравнение, в rest мы то же можем напихать для отладки чего лишнего. Из моего опыта данные во много раз перевешивают слово data и название функции + что бы не говорили а многие не оптимизируют и в результате на rest кучу лишних запросов - GraphQL лишён этих недостатков, разработка ускоряется, запросов меньше.
@@Kulibins1 Респонс для REST: 2.5 килобайта, для GraphQL: 3 килобайта.
Но может действительно в реальных условиях с более емкими запросами жила разница или пропадет или не будет так заметна.
Спасибо )
@@mihail8575 посмотрел, и понял почему у вас так, русские буквы в ответе превратились в \u0410\u0432\u0442\u043E\u0440 из-за этого разница в размере. Самое интересное, если поставить ResponseCompression на бэке, то сжатый ответ graphql оказался почему-то значительно меньше 2.9 kb против 8.2 у REST. Если не сжимать, то 84.5 против 61.5 kb у рест. Но у меня на рабочих проектах всегда стоит сжимать. Нужно посмотреть как настраивается сериализация для HotChocolate ( или чем вы пользуетесь )
Потому что это очередная абстракция,+ как она реализована внутри вопрос, если у вас в приложении работает , 20% это огромная потеря производительности, это будет заметно
@@ИванПошековский я уже ответил на этот вопрос нет такого что rest легче!!! Оно одинаково по размеру ответа. Тут дело в кодировке по умолчанию русского текста. В qraphql hot chocolate тоже можно убрать перекодирование и будет так же, более в rest изначально тоже русский текст через кодировку выдавал, пришлось опцию json серелизации выставлять. Я у себе провел замеры и в ответе на вопрос их выложил. Что rest что grapql это надстройки 🤣 только graphql не медленнее и гораздо фукциональнее , на написание бэка тратится гораздо меньше времени. Конечно если цель: бесконечная работа, то qraphql это минус, а если скорость, функциональность, то это qraphql. Целую статью на Хабре писал GraphQL: как сделать бэкенд приложения экономнее и быстрее habr.com/p/593115/
Классика жанра:)
Спасибо
Интересно, спасибо. Я правильно понял что сам GraphQL-сервер тоже написан на Ц#, а не запущена какая-то готовая сборка?
Да, исходники горячего шоколада лежат на GitHub
А что Вы используете в своем основном проекте для генерации отчетов на сайте?
У меня проекты больше это как замена десктопным приложениям. Раньше была своя система для отчётов. Сейчас хочу поизучать этот вопрос. Проектов много, команд много, посмотрю что кто использует.
@@Kulibins1 тоже как замена десктопу начал переносить на blazor проект. Пока проблема только с передачей файла. С отчётами есть идеи, но пока ищу все варианты.
Тогда в чем преимущество одного и другого, или графкл просто лучше и все?
С мой точки зрения GraphQL личе во всем. Но rest проще и более распространен, для некоторых стыковок различных систем между собой наверное лучше использовать rest
Ну да, если с фронта одним запросом графа можно забрать все данные, нежели рестом несколькими запросами с разных эндпоинтов.. И что тогда будет быстрее?
GraphQL быстрее, но в rest тоже можно сделать специальный запрос который сможет вернуть всё, REST не ограничен CRUD, но такие запросы нужно делать каждый раз, а их может быть много, и они заранее не известны.
1:30 дай пожалуйста ссылку на видео про хэш
Вопрос про это видео, наверное: ruclips.net/video/0Q5Pz5Ozsow/видео.html
3:31 говорит, что произвел нагрузочный тест, делая 100 запросов за 10 секунд, а результаты якобы говорят что-то о REST.
Конечно через postman это не прям супернагрузочное тестирование, да и запрос в бд тут реально без кэширования, запрос с join получается - но факт от этого не меняется, думал что накладные расходы у GraphQL будут выше, а оказалось что он не то что не медленее , но и чуть быстрее - Суть видео была сравнить на примере.
@@Kulibins1 20 - 80 миллисекунд для запроса на локальную машину - это очень медленно для небольших запросов. Думаю, дело не в том, что используется REST.
@@АнтонВоронов-ы9ц конечно там еще и запрос в базу данных
Неожиданно, интересно почему так?
Сам удивился, думал либо равны, либо REST на одинаковом результате будет быстрее, но вот результат: GraphQL в несколько раз быстрее. Может повлиял еще запрос в базу данных. Sql в горячем шоколаде, чуть от того что entity формирует отличается. Надо еще провести расширенные эксперименты. Изначально в видео хотел показать как тестить Postman, и взял пример, а оно вот как получилось.
REST в топку вслед за SOAP
Rest для всяких стыковок с другими системами очень даже хорошо.
Попробуй сервер на rust написать
Никогда не занимался rust 😉
@@Kulibins1 там крейт простой async-graphql. У меня схеиа очень простая, запрос в браузере поисходит за три милисекунды
@@maria_golubeva_nl за 3мс с обращением к postgresql?
@@Kulibins1 нет, статика из памяти
@@maria_golubeva_nl тут в примере из базы + запрос не просто select
Епте... Что тут можно мерить, если ты меряешь не сам graphql, а реализацию своих контроллеров. Все это http, так что без толку тут мерить.
Ну тут как раз и меряю все вместе, т.к. запросы идентичные 😉