GraphQL создает свою OpenSource foundation

Это так даже с REST.

В общем случае GET всегда содержит URL ресурса, но не обязан содержать список запрашиваемых полей (атрибутов ресурса). И рискну заявить, в подавляющем большинстве проектов и не содержит.

Более того, в HTTP content negotiation столь мелкая грануляция не стандартизирована (пока что, по крайней мере), так что кому надо — каждый волен лепить свой велосипед. Сабж выглядит достаточно прикольно, по крайней мере идеологически: вносит новое измерение, не противоречащее существующему базису REST; так что может когда и стандартизируют.

Хотя лично я этот сабж в гробу видал; например даже при рендеринге html-шаблонов когда-то напарывался на необходимость передавать в шаблон чувствительные данные, т.е. даже здесь предпочту server side ныне модным JS MVC. <брюзга>И вообще, дожили: MVC внутри view-слоя.</брюзга>

Принцип тот же: клиент сам решает, какие данные ему нужны

Это так даже с REST.

В общем случае GET всегда содержит URL ресурса

Нет разницы, каким именно способом клиент «решает, какие данные ему нужны».

дожили: MVC внутри view-слоя

Казалось бы, причем тут MVC и view.

Я не совсем понял как заоптимизировать этот граф в один sql-запрос.

В общем случае никак, разумеется. Гыгы, тут напрашивается оптимизирующий планировщик GraphQL-запросов, выбирающий например между N+1 и fetch join (в хиберовской терминологии, т.к. другой не помню). С хинтами. Хоть и попроще, чем SQL-оптимизаторы, в которые тысячи человеко-лет вбухнуто.

(веб-фреймворк есть такой, нихрена не умеет, но делает это очень быстро)

!

Чего не хватало в фальконе, что есть в drf?

Чего не хватало в фальконе, что есть в drf?

да всего, т.к. там просто ничего нет и все нужно самому реализовывать, начиная с сериализации, pagination, authentication & authorization. конечно, при наличии хорошей команды это вполне себе можно осуществить, но цена не сопоставима с выигрышем от такого решения, по сравнению с drf. вся эта «скорость» улетучится, как только будут добавлены все присущие нормальному rest api свойства. но команды профессионалов, способных грамотно релизовать это, стоят дорого. я бы сказал, что falcon - это классический пример nih-синдрома. вместо того, чтобы разрабатывать rest api, время тратится на разработку доморощенного rest api framework.

GraphQL is an open-source data query and manipulation language, and a runtime for fulfilling queries with existing data

Исчерпывающая информация!

сериализации

Встроена обертка над json.dumps(). И из коробки, навешивающий json-schema на ресурс. Или ты о какой-то другой сериализации?

authentication & authorization

Rest на то и rest что авторизация, как правило, по токенам или вообще basicauth. Подключаются одной строчкой

* декоратор, навешивающий json-schema на ресурс

сериализации

Встроена обертка над json.dumps(). И из коробки, навешивающий json-schema на ресурс. Или ты о какой-то другой сериализации?

нормальные rest api могут, по запросу клиента, выдавать ответ в xml и др. форматах. а эта обертка настолько примитивна, что бесполезна в сколь-нибудь серьезном проекте. о, я совсем забыл про валидацию и десериализацию запросов. опять же, не только из json.

authentication & authorization

Rest на то и rest что авторизация, как правило, по токенам или вообще basicauth. Подключаются одной строчкой

мало того, что токены бывают всевозможные, так ими еще и управлять надо. и всего этого просто нет. или есть наколенная поделка васи пупкина, которую он давно забросил и которую легче переписать, чем проверить, что она корректно работает и не содержит дыр. а access-control? тоже надо лепить свой.

вобщем, если писать микросервисы для сугубо внутреннего потребления, когда только json, пародия на аутентификацию и отсутсвием ограничений доступа, то, наверное, можно обойтись и тем, что есть. но ведь лемминги же на этом rest api для внешних потребителей лепят!

Сеньор моего сеньора — мой сеньор.

Может кто знает - Web-версия FB тоже через GraphQL работает или она напрямую работает с БД?

Так это что получается. В 90-х годах был Borland C++ Builder, где на формочку таскали контрольчики и из приложения лазали напрямую в базу данных. Получается, что хипстеры переизобрели эти рич аппликэйшенс на своих хипстерских инструментах?

Да! По кругу идет.

Получается, что хипстеры переизобрели эти рич аппликэйшенс на своих хипстерских инструментах?

Нет. GraphQL - не обязательно язык запросов к СУБД. Но ты _можешь_ использовать его как привык в C++Builder :)