Основная идея GraphQL — это возможность обьединять несколько операций в одном запросе. Такая необходимость вызвана тем, что если делать каждую операцию отдельно, то это увеличивает кол-во запросов к серверу и время работы, которое в основном истрачивается на сетевой пинга от клиента к серверу и обратно. Когда таких операций много, их время суммируется и из-за этого клиентская часть приложения заметно тормозит.
GraphQL позволяет обьединить все эти запросы в один скоп, отправить, а потом получить все ответы на них за один проход. Это дает экономию в количестве и суммарном времени выполнения операций.
Один из вариантов решения этой же проблемы, но без GraphQL, заключается в создании методов-агрегаторов, которые за один запрос позволяют обрабатывать сразу несколько "хотелок" клиента. Но тут возникает своя проблема, так как у каждого клиента могут быть разные потребности. Это приводит к тому, что методы-агрегаторы начинают плодиться как грибы под каждую прихоть клиента и из-за этого их становится трудно сопровождать.
GraphQL решает эту проблему, позволяя комбинировать требуемые операции в один запрос динамически на стороне клиента. Затем сервер принимает такой запрос, разгребает его по отдельным провайдерам, а потом формирует обьединенный ответ и отправляет клиенту.
Здравствуйте, Klikujiskaaan, Вы писали:
K>Нет, там тоже самое но по-другому. K>Endpoint там, да, один. Но это не отменяет того, что надо самому писать резолверы и датолоадеры.
Вообще, по-моему, идея лежит на поверхности — прикрутить к СУБД сразу возможность запроса не по SQL а по GraphQL, причем через Web, чтобы напрямую с браузера.
Здравствуйте, Aquilaware, Вы писали:
A>Основная идея GraphQL — это возможность обьединять несколько операций в одном запросе.
Еще выбрать нужные поля, а не все имеющиеся. Т.е. примерно как вместо SELECT * FROM — указать конкретные поля — SELECT Name FROM, чтобы не тянуть все.
Кстати, уже делают надстройки над СУБД, чтобы делать запросы напрямую на GraphQL к СУБД прямо из браузера. Права доступа тоже назначаются на уровне СУБД.
A>Один из вариантов решения этой же проблемы, но без GraphQL, заключается в создании методов-агрегаторов, которые за один запрос позволяют обрабатывать сразу несколько "хотелок" клиента. Но тут возникает своя проблема, так как у каждого клиента могут быть разные потребности. Это приводит к тому, что методы-агрегаторы начинают плодиться как грибы под каждую прихоть клиента и из-за этого их становится трудно сопровождать.
Здравствуйте, Shmj, Вы писали: S>Вообще, по-моему, идея лежит на поверхности — прикрутить к СУБД сразу возможность запроса не по SQL а по GraphQL, причем через Web, чтобы напрямую с браузера.
Там есть ещё несколько вопросов, которые нужно решить. В частности — модель безопасности, а также меры противодействия DoS/DDoS.
Но, в целом, идея — продуктивная. Иметь коробочную реализацию GraphQL поверх СУБД было бы во многих случаях лучше перспективе врукопашную поддерживать application server, который просто перекладывает байтики туда-сюда.
Что в целом ничуть не лучше килобайт этих дурацких CRUD-хранимок внутри СУБД.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Там есть ещё несколько вопросов, которые нужно решить. В частности — модель безопасности
Практически любая СУБД умеет точно настраивать права доступа, просто этим редко пользуются — обычно заводят одного пользователя для сайта. Но задумка то изначально была — СУБД управляет доступом.
Единственная загвоздка тут может быть — когда права завязаны не на сущности (таблицы, поля и т.д.) а на состояние. К примеру, перевести заказ в состояние "Подтвержден" должен иметь право создавший его клиент. А вот перевести в состояние "оплачен" — уже не должен иметь прав.
S>а также меры противодействия DoS/DDoS.
Здравствуйте, Shmj, Вы писали: S>Практически любая СУБД умеет точно настраивать права доступа, просто этим редко пользуются — обычно заводят одного пользователя для сайта.
Как правило, этого недостаточно. S>Но задумка то изначально была — СУБД управляет доступом.
Row-level security бывает не во всякой СУБД, и не всегда её модель совпадает с потребностями приложения. S>Единственная загвоздка тут может быть — когда права завязаны не на сущности (таблицы, поля и т.д.) а на состояние. К примеру, перевести заказ в состояние "Подтвержден" должен иметь право создавший его клиент. А вот перевести в состояние "оплачен" — уже не должен иметь прав.
Не единственная. Например, у пользователя есть права на просмотр своего профиля, но нет прав на просмотр чужого. S>Это решается на сетевом уровне.
Ах, если бы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не единственная. Например, у пользователя есть права на просмотр своего профиля, но нет прав на просмотр чужого. S>>Это решается на сетевом уровне.
Вроде в той же MS SQL по умолчанию пользователь создает схему имени себя. В других аналогично. В общем то это решается — просматривать/изменять те записи, которые ты сам создал.
А вот когда зависит от состояния — то уже потребуется слой бизнес-логики. В принципе и это можно дописать на уровне базы, но получится некий всемогутор.
Здравствуйте, Shmj, Вы писали: S>Вроде в той же MS SQL по умолчанию пользователь создает схему имени себя. В других аналогично. В общем то это решается — просматривать/изменять те записи, которые ты сам создал.
Вы что-то путаете. Схема — да. Но схема описывает таблицы, а не строки.
Чтобы "просматривать/изменять записи, которые сам создал" нужно где-то хранить информацию о том, кто что создал. Не говоря уже о том, что эта схема не покрывает нужных сценариев. S>А вот когда зависит от состояния — то уже потребуется слой бизнес-логики. В принципе и это можно дописать на уровне базы, но получится некий всемогутор.
Я себе это фантазирую в виде чего-то типа "хранимок", только не на убогой процедурной версии SQL, а на чём-то более приемлемом.
И вот эти "хранимки", или "табличные функции", или "параметризованные представления" уже торчат наружу по HTTP-протоколу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Вы что-то путаете. Схема — да. Но схема описывает таблицы, а не строки. S>Чтобы "просматривать/изменять записи, которые сам создал" нужно где-то хранить информацию о том, кто что создал. Не говоря уже о том, что эта схема не покрывает нужных сценариев.
Получается нужна авто-генерация всех методов для GraphQL на C#. И уже в самих методах править типовые сценарии, где это нужно.
Здравствуйте, Shmj, Вы писали: S>Получается нужна авто-генерация всех методов для GraphQL на C#. И уже в самих методах править типовые сценарии, где это нужно.
Да, что-то вроде интегрированного в СУБД C#. Точнее, может не C#, а какого-то языка с linq и прочими ништяками.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Aquilaware, Вы писали:
A>Основная идея GraphQL — это возможность обьединять несколько операций в одном запросе. Такая необходимость вызвана тем, что если делать каждую операцию отдельно, то это увеличивает кол-во запросов к серверу и время работы, которое в основном истрачивается на сетевой пинга от клиента к серверу и обратно. Когда таких операций много, их время суммируется и из-за этого клиентская часть приложения заметно тормозит.
Т.е. дано -- либо у нас на стороне клиента вызов типа DoSmthHardThenDoSmOtherHardAnd..., т.е. такой сложный аггрегатный вызов, что усложнит BL сервера, либо
DoThis1,DoThis2,DoThis3 ..., что вроде хорошо ложится на микросервисную арх-ру, но слишком большое latency. Т.е. если первый случай подойдет для монолита,
то второй для мс арх-ры, но долго. Решили придумать такую штуку, чтобы совместить лучшее из 2-х миров -- и сложные вызовы и микросервисы. Верно я это
понял? Соотв. в GraphQL мы размечаем граф вызовов соотв. микросервисов (я понятия не имею, как это делается, чисто фантазирую) для соотв. API вызова,
далее все это улетает на какой-нибудь gateway, который в это дело умеет, т.е. разбирает граф запросов, раскидывает их по микросервисам, собирает ответы,
и возвращает результат клиенту. Похоже на правду или фантизия? Кмк, оченно логичная технология для микросервисной арх-ры.
Здравствуйте, Sharov, Вы писали: S>Т.е. дано -- либо у нас на стороне клиента вызов типа DoSmthHardThenDoSmOtherHardAnd..., т.е. такой сложный аггрегатный вызов, что усложнит BL сервера, либо S>DoThis1,DoThis2,DoThis3 ..., что вроде хорошо ложится на микросервисную арх-ру, но слишком большое latency. Т.е. если первый случай подойдет для монолита, S>то второй для мс арх-ры, но долго. Решили придумать такую штуку, чтобы совместить лучшее из 2-х миров -- и сложные вызовы и микросервисы. Верно я это S>понял?
Не совсем. Do подразумевает какую-то императивщину с изменением состояния.
А GraphQL, как и какой-нибудь RQL — это запросы.
Проблема с запросами — как раз в том, что всем надо много всего и немножко по-разному.
Делаем один метод GetSmthingList(), который возвращает всё-всё — дофига данных, тормозит.
Делаем метод GetSmthingIDs(), который возвращает список ID, и метод GetSomethingDetailByID(), который возвращает детали только для одного — простейшие вещи приходится делать через N+1 вызов.
Делаешь метод GetSmthingListWithNameAndAddressOnly() — методов становится слишком много. Одному — имя, другому — адрес, третьему — всё кроме фото; одному — по диапазону дат регистрации, другому — по префиксу фамилии, и так далее.
Появляется искушение выставить наружу какой-то API для критериев отбора, набора атрибутов в проекцию, и состава данных для связей.
Гольный SQL — это too big gun. Уж очень в нём много способов напороть. Например, можно уложить любую СУБД, просто скормив туда select * from users, users, users, users, users, users, users, users.
Уже при 10 записях в таблице эта штука отдаст 100 миллионов результатов. А если их там пара десятков тысяч?
Так что сейчас с разной степенью успеха изобретаются различные языки кастрированных запросов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>>Т.е. дано -- либо у нас на стороне клиента вызов типа DoSmthHardThenDoSmOtherHardAnd..., т.е. такой сложный аггрегатный вызов, что усложнит BL сервера, либо S>>DoThis1,DoThis2,DoThis3 ..., что вроде хорошо ложится на микросервисную арх-ру, но слишком большое latency. Т.е. если первый случай подойдет для монолита, S>>то второй для мс арх-ры, но долго. Решили придумать такую штуку, чтобы совместить лучшее из 2-х миров -- и сложные вызовы и микросервисы. Верно я это S>>понял? S>Не совсем. Do подразумевает какую-то императивщину с изменением состояния. S>А GraphQL, как и какой-нибудь RQL — это запросы. S>Проблема с запросами — как раз в том, что всем надо много всего и немножко по-разному. S>Делаем один метод GetSmthingList(), который возвращает всё-всё — дофига данных, тормозит. S>Делаем метод GetSmthingIDs(), который возвращает список ID, и метод GetSomethingDetailByID(), который возвращает детали только для одного — простейшие вещи приходится делать через N+1 вызов. S>Делаешь метод GetSmthingListWithNameAndAddressOnly() — методов становится слишком много. Одному — имя, другому — адрес, третьему — всё кроме фото; одному — по диапазону дат регистрации, другому — по префиксу фамилии, и так далее. S>Появляется искушение выставить наружу какой-то API для критериев отбора, набора атрибутов в проекцию, и состава данных для связей. S>Гольный SQL — это too big gun. Уж очень в нём много способов напороть. Например, можно уложить любую СУБД, просто скормив туда select * from users, users, users, users, users, users, users, users. S>Уже при 10 записях в таблице эта штука отдаст 100 миллионов результатов. А если их там пара десятков тысяч?
Ну вот пришла рассылка от bytebytego(раскручивают тему system design interview), так там прямо пишут:
GraphQL is a query language for APIs developed by Meta. It provides a complete description of the data in the API and gives clients the power to ask for exactly what they need.
GraphQL servers sit in between the client and the backend services.
GraphQL can aggregate multiple REST requests into one query. GraphQL server organizes the resources in a graph.
GraphQL supports queries, mutations (applying data modifications to resources), and subscriptions (receiving notifications on schema modifications).
+
картинка
Не так уж я не прав был, это не просто еще один язык запросов.
Здравствуйте, Sharov, Вы писали:
S>Не так уж я не прав был, это не просто еще один язык запросов.
Да, похоже вы были правы, а я поверхностен.
Надо посмотреть на него повнимательнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
