Comments 42
Я бы говоря о graphql в первую очередь акцентировал внимание на тот момент что
graphql это фактически стандарт
graphql это система которая жёстко связывает программный код и документацию. Документация всегда и на 100% актуальна
graphql позволяет без изменения на стороне бэкэнда делать запросы нескольких разнородных объектов в одном запроса, выбирать только необходимые для работы поля объектов, в том числе выбирать или не выбирать поля связанных объектов произвольной вложенности
graphql это фактически стандарт
graphql это система которая жёстко связывает программный код и документацию. Документация всегда и на 100% актуальна
graphql позволяет без изменения на стороне бэкэнда делать запросы нескольких разнородных объектов в одном запроса, выбирать только необходимые для работы поля объектов, в том числе выбирать или не выбирать поля связанных объектов произвольной вложенности
Может я не понимаю, но мне кажется, что graphql, это всего-лишь описание языка запросов. facebook, ещё создал описание того, как рекомендуется реализовывать логику запросов на клиенте и логику выдачи на сервере. То есть, api как было, так и осталось, только теперь оно не на уровне https, а на программном уровне. Ведь один контроллер не может делать все и сразу, придется разбить логику на множество контроллеров. Но доступ к ним будет не через https, а черз один рутовый контроллер. Кроме того описание того, как работать с логикой, придумали уже давно, это клиентское и серверное orm. Разница только в том, что они не в функциональном стиле и их придумали не в facebook.
Да, удобства от использования действительно есть. Но достигается оно за счет того, что из любого места приложения можно получить любые данные. То есть данные лежат в общей куче. В ооп, такое просто не допустимо. Но лично мне, как лежат данные, если их раскладываю не я лично, безразлично. Поэтомуон действительно делает работу проще и понятнее, при условии что есть готовые библиотеки, которые покрывают все потребности. Иначе придется окунутся в мир того, что только вчера придумали.
Да, удобства от использования действительно есть. Но достигается оно за счет того, что из любого места приложения можно получить любые данные. То есть данные лежат в общей куче. В ооп, такое просто не допустимо. Но лично мне, как лежат данные, если их раскладываю не я лично, безразлично. Поэтомуон действительно делает работу проще и понятнее, при условии что есть готовые библиотеки, которые покрывают все потребности. Иначе придется окунутся в мир того, что только вчера придумали.
Вы правильно поняли. Но это как раз то чего не хватает restapi описания то есть стандарта, пусть даже не утвержденного сообществом. Попытка создать стандарт для restapi это jsonapi. Если сравнить с graphql то graphql проще и мощнее. Плюс встроенная документация и даже консоль для тестовых запросов.
Есть swagger. Не знаю можно ли его рассматриватт как некий стандарт но штука мощная с консолью и документацией.
Swagger который теперь openapi это стандарт. Но стандарт в котором они определяются сервисы отдельно от реализации. То есть swagger отчасти созвучен graphql но не гарантирует соответствие сервисов их описанию в то время как graphql описание сервисов неразрывно связано с их реализацией и не может в принципе разойтись. Кроме того будет обеспечена валидация входных и выходных параметров сервиса при их вызове на соответствие описанию.
С orm все хорошо пока Вам нужно вернуть плоский объект. Когда нужно вернуть скажем объект со связями то сразу возникает вопрос. А нужно ли возвращать связанные объекты? А все ли связанные объекты нужно возвращать? А нужно ли возвращать связанные объекты со связанными объектами и так далее по рекурсии. Если например нужно вернуть более одного разнородного объекта то это уже для фрнймвкркам задача не тривиальная. Плюс документация. Никто не когда не сталкивался с устаревшей документацией?
Смешались в кучу, кони, люди…
API никогда и нигде не было на уровне https. Потому что https это транспортныый уровень, а не програмный. И graphql и rest и даже soap используют https для безопасного соединения, а не для реализации API.
В нормальном сервисе доступ всегда будет через https. А вот количество ендпоинтов в сервисе будет разным. В rest приложении будет много ендпоинтов, условно «на каждый случай». А в приложении с graphql будет один эндпоинт позволяющий получать различные данные.
То есть, api как было, так и осталось, только теперь оно не на уровне https, а на программном уровне.
API никогда и нигде не было на уровне https. Потому что https это транспортныый уровень, а не програмный. И graphql и rest и даже soap используют https для безопасного соединения, а не для реализации API.
Но доступ к ним будет не через https, а черз один рутовый контроллер.
В нормальном сервисе доступ всегда будет через https. А вот количество ендпоинтов в сервисе будет разным. В rest приложении будет много ендпоинтов, условно «на каждый случай». А в приложении с graphql будет один эндпоинт позволяющий получать различные данные.
HTTP, несмотря на парадоксальную расшифровку букв в своей аббревиатуре, является прикладным протоколом, application layer.
API никогда и нигде не было на уровне https. Потому что https это транспортныый уровень, а не програмный. И graphql и rest и даже soap используют https для безопасного соединения, а не для реализации API.
К сожалению, rest API строится именно на уровне http (можно без s). Так называемый HTTP REST — это надстройка над http, который строго говоря, именно программный уровень. Можно использовать http исключительно как транспортный уровень, но для этого приложение не должно знать тонкости реализации уровня http, например не обрабатывать http коды ответов, что противоречит «правильному» rest.
К сожалению, rest API строится именно на уровне http (можно без s). Так называемый HTTP REST — это надстройка над http, который строго говоря, именно программный уровень. Можно использовать http исключительно как транспортный уровень, но для этого приложение не должно знать тонкости реализации уровня http, например не обрабатывать http коды ответов, что противоречит «правильному» rest.
Строго говоря, в оригинальном определении REST про правильные коды HTTP ничего нет, даже использование GET для запроса ресурса приводится лишь как пример. Все требования, о которых Вы пишете, придумали позднее.
В статье идёт скорее всего не о rest а о restapi. Rest это принципы построения приложений которое мы используем даже тогда когда об этом не подозреваем. Restapi это конкретно н где строго не описанная и не стандартизированная фича которая реализует crud сервисы посредством http методов put, get, update, delete и как вишенка в торте patch. Поначалу этот restapi очаровывает своей простотой. Потом когда переходишь от функционала todoapp к реальным приложениям, начинаешь желать чего то более стандартизированного.
Кстати restapi не выполняет всех принципов rest ТК как правило полагается на данные сессии клиента которые есть ни что иное как хранение состояния приложения на сервере. Я уже не говорю о смешении транспортного протокола с протоколом уровня приложения. Например сходу разобрать чего нет на сервере получив 404 ответ невозможно. user/joe — 404 это в базе нет пользователя Джо или же нет url user ТК сервис расположено по url users?
Кстати restapi не выполняет всех принципов rest ТК как правило полагается на данные сессии клиента которые есть ни что иное как хранение состояния приложения на сервере. Я уже не говорю о смешении транспортного протокола с протоколом уровня приложения. Например сходу разобрать чего нет на сервере получив 404 ответ невозможно. user/joe — 404 это в базе нет пользователя Джо или же нет url user ТК сервис расположено по url users?
Может я не понимаю, но мне кажется, что graphql, это всего-лишь описание языка запросов
а так же описание как эти запросы обрабатывать на стороне сервера. Другими словами это стандарт на API.
То есть данные лежат в общей куче
какие данные? чьи данные? в какой общей куче? На сервере у вас точно та же БД, что и была.
В ооп, такое просто не допустимо.
причем здесь ООП? Мы же про апи разговариваем.
я про клиент. реализации, которые я видел, на клиенте все данные хранят в общем хранилище и доступны в любой части программы по запросу.
State management никак не связан с REST или GraphQL.
я знаю что нет. и мне безразлично, что запросы к state manager выполняются путем строковых query, что просто распахивает ворота к ним для всех частей программы. главное удобно и быстро. Но не правильно! мне кажется, что эволюцию не должна деградировать. Это я относительно клиентской части говорю.Там так все таким образом эволюционирует, как-будто java и c# их ничему не научили.
как уже сказали, с помощью state management строятся современные js-приложения, работающие с api или не работающие с api.
Ребята, а как разруливать права доступа в graphql?
Этот вопрос graphql не ркшает. Скорее всего его Фейсбук делает это разделение на другом уровне приложения. С разделением доступа насколько мы знаем у них всё в порядке. Друзей друзей не выдают. Кому не следует по api
Если API у роли полностью отличается, то это делается отдельным инстансом graphql (например, для админки и для пользователя полностью отличаются входные/выходные данные).
Если АПИ более-менее похожий, то разруливается на уровне резолверов.
Если используете Apollo, то вот есть статья, где расписывается как они работает через директивы: www.apollographql.com/docs/guides/access-control.html
Если АПИ более-менее похожий, то разруливается на уровне резолверов.
Если используете Apollo, то вот есть статья, где расписывается как они работает через директивы: www.apollographql.com/docs/guides/access-control.html
Я сейчас думаю так сделать, на каждую роль сгенерировать свою схему доступа к определенным ресурсам и полям ресурсов. И помере прохождения пользователя по уровням авторизации переключать схемы. Мне не хочется решать на уровне резолверов, тк злоумышленник сможет видеть всю схему. Да можно разделить на 2 части (паблик, админ). Я считаю — что дано ролью то и пользователь должен видеть. + на основе схемы можно сразу строить фронт, отключая определенные элементы ui в зависимости доступности ресурсов. К примеру — нет доступа на создание статьи — нет формы. Я вижу это самым перспективным. Еще можно реализовать crud на клиенте, если дать всем типам вменяемые название. user_create, user_find, user_update, user_remove — первая часть до последнего нижнего подчеркивает складывается и на клиенте можно сделать объект user с 4-мя методами. ИМХО
По поводу того что злоумышленник сможет видеть схему. Фейсбук опубликовал документацию на сервисы а которым доступ может получить и любое приложение и приложение после размещения клиента на доступ и по приложение которое запросило дополнительный доступ на Фейсбуке. Я лично такого никогда не получал думаю это не бесплатно. Так что схему в был все а доступ имеют не все.
Конечно есть у них и какие то админские схемы, скорее всего, на и внутри этих админские схемы также доступ разделен по полям и тп. Вообще тема разделения доступа в graphql пока открыта. И разделение схем это не решение ТК даже для самых простых случаев например типа блогов. Я и кю доступ к редактированию своих статей и к чтению чужих и тп не будешь же каждому юсеру свою схему давать
Конечно есть у них и какие то админские схемы, скорее всего, на и внутри этих админские схемы также доступ разделен по полям и тп. Вообще тема разделения доступа в graphql пока открыта. И разделение схем это не решение ТК даже для самых простых случаев например типа блогов. Я и кю доступ к редактированию своих статей и к чтению чужих и тп не будешь же каждому юсеру свою схему давать
Я и кю доступ к редактированию своих статей и к чтению чужих и тп не будешь же каждому юсеру свою схему давать— это одна схема, только какие именно записи можно решить на resolve. Но если есть различие, к примеру — кто-то может удалять комментарии — это уже 2 схемы. Не надо давать каждому схему, но отделить различные, по мне, лучше сразу на этапе генерации. Это более секьюрно, когда невидно что и как происходит на сервере. Сервер всегда должен быть черной коробкой для клиента.
можно ли воспринимать graphql как современную реинкарнацию soap?
По функции в приложении да. Но по функциональности нет.
На soap не особенно и похоже, а вот на OData да.
Похоже! 1-в-1, только на новомодных JSON'ах вместо старых-добрых XML-ей :trollface:
SOAP и GraphQL прям как близнецы-братья. Оба заявляют независимость от транспортного протокола, оба описывают формат взаимодействия и требуют описания схемы передаваемых данных (у SOAP — это WSDL), в которой описываются запросы и возвращаемые типы.
В SOAP жестко задан набор методов, с форматов запроса и ответа, RPC по сути. В GraphQL можно по одному ендпоинту вытянуть самые разлиные данные, так запрос на выборку формируется непосредственно на клиентской стороне. А вот в OData запрос как раз формируется на клиенте, GraphQL оттуда идея видимо и взяли и добавили легковестности и свой синтаксис запросов. Схожесть разе что в том что нужно описывать схему взаимодествия, но по этому признаку 90%+ всех форматов клиент-сервер взаимодействий будут похожи. К тому же SOAP громоздкая штуковина сама по себе.
Скорее как SQL-like интерфейс к удаленным данным работающий по HTTP.
Нет решение основанных на Java, которые позволяют вам использовать GraphQL вместе с обнаружением сервисов, балансировщиком или API gateway из коробки
Балансировка и транспорт между сервисами это больная проблема подхода микросервисов. Сейчас в принципе нет простого подхода для решения проблем взаимодействия между отдельными сервисами.
UFO just landed and posted this here
Пусть меня заминусуют, но до WS-SOAP, где и асинхронность и распределенные транзакции и безопасность и не только http — им всем еще расти и расти, а там может и измениться веб.
Что Вы имеете в виду WS-SOAP не нашел такой аббревиатуры в поисуовой выдаче?
Никто не спорит с тем что SOAP мощный протокол. Но все же graphql имеет преимущество по сравнению с SOAP, хотя имеет и недостатки.
Я эти преимущества уже перечислил.
Graphql позволяет запрашивать произвольное количество разнородных объектов в одном запроса
Graphql позволяет запрашивать только необходимые поля и необходимые вложенные объекты
Graphql не только язык описания сервисов но имеет также принципы построения бэкэнда на основании функций resolver которые обеспечивают вот эту самую указанную выше функциональность.
Ну и в дополнение скажу что soap чрезмерно сложен. Хотя конечно проще чем CORBA. Не даром повсеместно вытесняет restapi. Из технологий которые имеют полноценную поддержку soap кроме к Майкрософт, это java, php, 1с. Node.js имеет две библиотеки и то с ограниченной поддержкой. Graphql все же проще. Он очень прост для понимания.
Вроде же уже не один суд принял решение, что API не являются интеллектуальной собственностью.
UFO just landed and posted this here
Ну ws не такая однозначно принятая аббревиатура. В качестве аббревиатуры чаще применяется для веб сокетов ws://
Я именно и подумал что вы на советах предлагаете это сделать в первую очеркдь.
Я именно и подумал что вы на советах предлагаете это сделать в первую очеркдь.
UFO just landed and posted this here
Да не проблема в веб-сервисах запросить разнородные объекты. Весь вопрос в том что доля этого их предварительно необходимо описать для каждого случая. А в graphql это решает разработчик клиентской части приложения исходя из свои потребностей. Кстати graphql библиотеки не только на nodejs есть.
А кардинальное отличие graphql от swager/openapi в том что swaber/openapi это стандарт описания сервисов который даёт средство для документирования и запросов, но который никакие связан с кодом самих сервисов. Поэтому не гарантируется их соответствие. В graphql определение и документация серыисов является частью исполняемого кода поэтому всегда гарантируется их полная согласованность.
А кардинальное отличие graphql от swager/openapi в том что swaber/openapi это стандарт описания сервисов который даёт средство для документирования и запросов, но который никакие связан с кодом самих сервисов. Поэтому не гарантируется их соответствие. В graphql определение и документация серыисов является частью исполняемого кода поэтому всегда гарантируется их полная согласованность.
UFO just landed and posted this here
Если бы производство нового останавливалось на ресерче старого рынка, то утром бы на работу вы поехали на бричке, и, дай бог, хотя бы на самоедущей, а не запряженной конями.
Суть не только в том, чтобы решить все проблемы связанные с апи и подготовить по этому документацию. Решение должно быть как можно проще, удобнее. Оно должно быть повернуто спиной к разработчику. И не только разработчику, который бородат и в свитере, но и только что вылупившемуся из яйца фронтендеру.
Если odata за 10+ лет так и осталась уделом 2.5 энтепрайзеров, то что-то здесь не так.
UFO just landed and posted this here
Sign up to leave a comment.
Статья удалена