Индексы часто подгоняют под запросы. Кроме того это 2-е разные темы, одна другой не мешает, а лишь помогает. GraphQL не мешает вам использовать какой угодно запрос, хоть хранимку вызывайте. GraphQL наоборот поможет вам более оптимальные запросы сделать.
Это вводная статья, конкретика будет в следующих статьях (уже есть в видео)
GraphQL легко заменяет REST
Вложенность легко ограничивается. Была такая форма атаки, когда спамили гигантскими вложенными запросами. Это давно решено
Тем чем я пользуюсь. Умеет делать пагинацию из коробки причём как минимум 3х видов: курсоры, сдвиги, и вы можете вообще свою реализацию подкинуть.
GraphQL очень применим для связи фронта и бэка. А вот для связи микросервисов между собой, я предпочитаю шину.
Один суперответ(хотя прям такое редко случается), больше сгруппированные запросы, вам помогают оптимизировать запрос в БД, а так же ответ сервера, почитайте материалы Facebook где они показывают, насколько сократилось потребление энергии в мобильном устройстве, а это огромный + в наше время.
GraphQL позволяет отказаться от REDUX (лично я его не долюбливаю)
В общем вижу плюсы, а минусов не вижу. Есть моменты котрые я бы хотел еще более развить в GraphQL, например выполнять в одном запросе и чтения и записи.
Я еще пользовался OData, про него тоже расскажу. Но всё-таки GraphQL гораздо удобнее.
Даже подписки вы можете делать оптимизированными и говорить что из полей вы хотите получать. + один стандарт определяет всё что нужно, а не несколько разных.
Я понимаю что на вкус и цвет у каждого свои предподчтения, поэтому нет плохих стандартов. Это как в анекдоте: было 10 стандартов, мы придумаем супер стандарт который в 1000 раз лучше, и так появляется 11-й стандарт, потом 12-й.
Честно не знаю как там на пайтоне, но на C# .net Core и hot chocolate можно меньше кода писать. У вас в запросе вы можете писать аналог SQL WHERE, где можете делать условия, эти условия транслируются потом в запрос SQL. На бэке мы имеем не так много функций, а фронт может вызвать функцию с условиями как вашими, так и универсальными, я этот момент рассматривал. На фронте часто приходится по требованию заказчика переигрывать какие-то моменты, и тогда, не нужно дорабатывать бэк.
Кроме того группировка запросов увеличивает скорость работы, на мобилках меньше батарейку ест. Да можно сделать оптимальные REST запросы, но в GraphQL это делается чуть ли не автоматом, а на REST вам каждый раз нужно все руками делать, и это может занимать много человекочасов. Я думал что REST при одинаковых условий будет чуть быстрее, но по моим тестам, наоборот GraphQL оказался быстрее, с результатами можете ознакомиться.
Я разработчик на .net core ( раньше работал много лет и со старым . net framework ). Все примеры как раз на . net5 (на 6 переведу в ближайшее время) С поддержкой все очень хорошо, есть библиотека hot chocolate, которая встраивается в pipeline, она полностью бесплатная очень мощная, и с открытым кодом. Сам работаю последние года с entity framework, который и используется на бэке для работы с данными, а уже GraphQL через него, великолепно работает. Функциональности выше крыши, тут скорее нужно посмотреть что есть, что бы свои костыли не изобретать, многие вещи делаются буквально пару строк кода. Каких-то сложностей нет, всё что с моего взгляда чуть сложнее рассказываю и еще несколько материалов точно будет.
Его плюсы в том что вы пишите гораздо меньше кода со стороны бэка. Кроме того ваши запросы, в которых вы выбираете только необходимые данные, они трансформируются в SQL с полями только теми что вы выбрали в запросе GraphQL (это показывал в одном из видео).
Тема «проблема n+1» решённая :) по крайней мере в библиотеке со стороны бэка «Hot Chocolate».
Отвечая про join. Почему это будет несколько запросов? Будет именно join. Так же в видео это показывал.
У меня есть видео GraphQL где я сравниваю производительность REST и GraphQL. Я думал что будет равенство, а получилось что GraphQL быстрее.
REST хорошая вещь, но уже реально устаревшая, многие функции приходится решать внешними «расширителями», например даже swagger (open API) это расширение, и много мелких проблем, когда при любом чихе мы делаем новую работу на бэке, ну или оставляем не оптимальные запросы, поверьте знаю о чём говорю. На канале по REST 19 видео, а GraphQL пока 8.
Эта статья вводная. Тема GraphQL довольно обширная, возможностей очень много. Последовательно разбираю тему в видео. То что вы описываете, называется Федерации, и да ях их конечно же использую.
По фронту буду в ближайшее время записывать. Как раз учту этот вопрос, и покажу как со стороны бэка, так и фронта.
т.к. вы можете в GaphQL получать ровно те данные которые запрашиваете, то вы пишете запрос, в плейграунде, или для основных фреймворков есть помощники, это когда вы пишите с intellisense это гораздо круче.
У себя на канале я делал видео и по REST и GraphQL. Автогенерацию тоже разбирал.
В статье очень подробно рассказываю. Что "механизм" внедрения зависимостей и Паттерн интверсии зависимостей это разные понятия.
Все показал на примерах. Потому что новичкам тяжело понять, те определения из википедии, на которые ссылаетесь. Даже подготовленному специалисту трудно с первого раза вникнуть в такие "заумные" определения. Для того что бы объяснить начинающему почему Angular это классный framework, старался рассказыть понятно.
Согласен с вами. Я не перепечатывал определение из вики. Попытался выразить своими словами, больше на практику опираясь. Часто новичку тяжело понять заумные определения, хотелось бы чтобы и ему было понятно.
Способ регистрации providedIn это отдельный пункт, он рассмотрен после регистрации в разделе провайдеров. Да тут еще есть много тонкостей которые хотелось бы показать. Буду это в роликах делать.
Индексы часто подгоняют под запросы. Кроме того это 2-е разные темы, одна другой не мешает, а лишь помогает. GraphQL не мешает вам использовать какой угодно запрос, хоть хранимку вызывайте. GraphQL наоборот поможет вам более оптимальные запросы сделать.
Это вводная статья, конкретика будет в следующих статьях (уже есть в видео)
GraphQL легко заменяет REST
Вложенность легко ограничивается. Была такая форма атаки, когда спамили гигантскими вложенными запросами. Это давно решено
Тем чем я пользуюсь. Умеет делать пагинацию из коробки причём как минимум 3х видов: курсоры, сдвиги, и вы можете вообще свою реализацию подкинуть.
GraphQL очень применим для связи фронта и бэка. А вот для связи микросервисов между собой, я предпочитаю шину.
Один суперответ(хотя прям такое редко случается), больше сгруппированные запросы, вам помогают оптимизировать запрос в БД, а так же ответ сервера, почитайте материалы Facebook где они показывают, насколько сократилось потребление энергии в мобильном устройстве, а это огромный + в наше время.
GraphQL позволяет отказаться от REDUX (лично я его не долюбливаю)
В общем вижу плюсы, а минусов не вижу. Есть моменты котрые я бы хотел еще более развить в GraphQL, например выполнять в одном запросе и чтения и записи.
Я еще пользовался OData, про него тоже расскажу. Но всё-таки GraphQL гораздо удобнее.
Даже подписки вы можете делать оптимизированными и говорить что из полей вы хотите получать. + один стандарт определяет всё что нужно, а не несколько разных.
Я понимаю что на вкус и цвет у каждого свои предподчтения, поэтому нет плохих стандартов. Это как в анекдоте: было 10 стандартов, мы придумаем супер стандарт который в 1000 раз лучше, и так появляется 11-й стандарт, потом 12-й.
Запросы пишутся с подсказками на раз два. Просто наверное еще непривычно, буквально дня 2 и уже всё понятно и быстро.
Честно не знаю как там на пайтоне, но на C# .net Core и hot chocolate можно меньше кода писать. У вас в запросе вы можете писать аналог SQL WHERE, где можете делать условия, эти условия транслируются потом в запрос SQL. На бэке мы имеем не так много функций, а фронт может вызвать функцию с условиями как вашими, так и универсальными, я этот момент рассматривал. На фронте часто приходится по требованию заказчика переигрывать какие-то моменты, и тогда, не нужно дорабатывать бэк.
Кроме того группировка запросов увеличивает скорость работы, на мобилках меньше батарейку ест. Да можно сделать оптимальные REST запросы, но в GraphQL это делается чуть ли не автоматом, а на REST вам каждый раз нужно все руками делать, и это может занимать много человекочасов. Я думал что REST при одинаковых условий будет чуть быстрее, но по моим тестам, наоборот GraphQL оказался быстрее, с результатами можете ознакомиться.
Я разработчик на .net core ( раньше работал много лет и со старым . net framework ). Все примеры как раз на . net5 (на 6 переведу в ближайшее время) С поддержкой все очень хорошо, есть библиотека hot chocolate, которая встраивается в pipeline, она полностью бесплатная очень мощная, и с открытым кодом. Сам работаю последние года с entity framework, который и используется на бэке для работы с данными, а уже GraphQL через него, великолепно работает. Функциональности выше крыши, тут скорее нужно посмотреть что есть, что бы свои костыли не изобретать, многие вещи делаются буквально пару строк кода. Каких-то сложностей нет, всё что с моего взгляда чуть сложнее рассказываю и еще несколько материалов точно будет.
Тема «проблема n+1» решённая :) по крайней мере в библиотеке со стороны бэка «Hot Chocolate».
Отвечая про join. Почему это будет несколько запросов? Будет именно join. Так же в видео это показывал.
У меня есть видео GraphQL где я сравниваю производительность REST и GraphQL. Я думал что будет равенство, а получилось что GraphQL быстрее.
REST хорошая вещь, но уже реально устаревшая, многие функции приходится решать внешними «расширителями», например даже swagger (open API) это расширение, и много мелких проблем, когда при любом чихе мы делаем новую работу на бэке, ну или оставляем не оптимальные запросы, поверьте знаю о чём говорю. На канале по REST 19 видео, а GraphQL пока 8.
По фронту буду в ближайшее время записывать. Как раз учту этот вопрос, и покажу как со стороны бэка, так и фронта.
У себя на канале я делал видео и по REST и GraphQL. Автогенерацию тоже разбирал.
В статье очень подробно рассказываю. Что "механизм" внедрения зависимостей и Паттерн интверсии зависимостей это разные понятия.
Все показал на примерах. Потому что новичкам тяжело понять, те определения из википедии, на которые ссылаетесь. Даже подготовленному специалисту трудно с первого раза вникнуть в такие "заумные" определения. Для того что бы объяснить начинающему почему Angular это классный framework, старался рассказыть понятно.
Согласен с вами. Я не перепечатывал определение из вики. Попытался выразить своими словами, больше на практику опираясь. Часто новичку тяжело понять заумные определения, хотелось бы чтобы и ему было понятно.
Способ регистрации providedIn это отдельный пункт, он рассмотрен после регистрации в разделе провайдеров. Да тут еще есть много тонкостей которые хотелось бы показать. Буду это в роликах делать.