Что же такое этот GraphQL?

Верно ли я понимаю, что речь идёт именно о некоем аналоге SQL?

Нет, скорее речь идёт о замене/дополнению к REST API – своеобразной форме взаимодействия (язык общения, если угодно) между клиентом и сервером.

Что такое «полностью статическое клиентское React-приложение»?

Знаю React поверхностно, так что могу быть неправ. Скорее всего автор имеет ввиду создание статических страниц (наподобие GitHub Gist), причём Gatsby собирает их на компьютере разработчика, делая запросы к БД при помощи GraphQL, собирая всё так, что при работе сайта БД уже не требуется, так как все необходимые данные были получены при сборке и были интегрированы в саму страницу.

Существует ли какая-нибудь готовая теория (или фрагмент теории) запросов описываемого вида?

Не понял вопроса. Теория – сама эта статья, есть примеры кода, есть ссылки на учебники, руководства. Или вы имеете ввиду что-то другое?

взглянуть на архитектуру базы данных

GraphQL не привязан к структуре базы: в базе данных может не существовать полей author или commentsCount – согласно примеру, посты могут храниться в postgres, поле commentsCount будет каждый раз подсчитываться:

SELECT COUNT(*) FROM comments WHERE post_id=$1

Ещё какие-то вещи могут хранится в Redis и т.д., а GraphQL обеспечивает единый механизм доступа к этим данным и необходимую вложенность

Хороший вопрос.
Решение "в лоб" – ограничить уровень вложенности.
Более сложное – вычислять циклы, как это делает nodejs, когда вы делаете

> a = {number: 1}
> a.me = a
> console.log(a)
{ number: 1, me: [Circular] }

То есть просто не отдавать посты для автора, для которого посты уже были отданы

Да, вы правы, с GraphQL действительно вытащить всю базу проще, чем используя, например, REST, где пришлось бы делать по запросу на категорию, потом по запросу на каждый товар и т.д.
Но и используя REST возможно это сделать. Как решается эта проблема? Самое простое решение – ограничивать число запросов с одного IP за какое-то время.
В случае GraphQL такое сделать сложнее, но всё же возможно: указывать максимальный limit для товаров и т.д. Я думаю что с распространением GraphQL будут разработаны методы защиты от таких атак.

Также, помня что эта технология была разработана Facebook, можно посмотреть как они борются с подобным (и борются ли вообще?)

собственно это не проблема graphql как спеки. Неразумно пенять на спецификацию, созданную для удобного доступа к данным, за удобный доступ к данным.
Серверную часть же вы пишете, в том числе ресолверы, валидацию помимо схемы, авторизацию/аутентификацию, рейт лимитинг. Не хотите скраперам отдавать данные — позаботьтесь об этом.

Backend будет отдавать только то, что вы его "научите" отдавать.
Frontend будет запрашивать только то, что ему нужно для отображения пользователю.

1. ....
2. http://graphql.org/learn/pagination/
3. http://graphql.org/learn/schema/#union-types
4. не совсем понял
5. можно передавать несколько мутация в одном запросе

Отвечаю с точки зрения GraphQL, а не конкретной библиотеки

1. Эта проблема однозначно решаема. Либо расширением спецификации, чтобы было возможно писать

   
   

   query getMyPost($fromId: Int, $toId: Int) {
     post(id: {ge: $fromId, le: $toId}){
       title
     }
   }

   
   

   примерно как это реализовано в mongodb
   либо даже без изменения спецификации:

   
   

   query getMyPost($fromId: Int, $toId: Int) {
     post(fromId: $fromId, toId: $toId){
       title
     }
   }

   
   

2. Лимиты и пагинация (видимо имеется в виду указание offset-а) могут быть также реализованы через аргументы и ограничены на backend-е до нужных значений (чтобы нельзя было запросить сразу миллион документов). Ну и документ по ссылке из сообщения VlastV

   
   

3. Также VlastV дал ссылку, там вроде то, что нужно

   
   

4. Можно создать endpoint user и при запросе без аргументов отдавать всех пользователей (не больше определенного количества конечно), при указании id выдавать конкретного пользователя, при указании списка из нескольких id или ограничений (from..to) пользователей с соответствующими id.

   
   
5. Можно сделать один endpoint, через него получать данные, через него же и устанавливать (аргумент set, например, будет устанавливать новое значение для поля). Это плохое решение, лучше разделять получение данных и установку (и запросы GET/POST), но технически можно сделать даже одним endpoint-ом.

Похожий подход используется в YouTube API кстати. Но видимо Facebook было этого мало.
Вообще, если смотреть на GraphQL и на такой способ определения необходимых полей, то создаётся впечатление, что это – урезанная версия GraphQL, ну или адаптация его под REST. Возможно что только у меня.
Ну и этот вариант не умеет в именованные запросы, параметры, типизацию и другое что умеет GraphQL

Я вот всё никак не пойму — первый пример (со списком полей) действительно настолько проблемный

настолько или не настолько — не важно. есть пул проблем при работе с апи. ФБ их взял, переосмыслил и реализовал в единой спеке. Каждая проблема из этого пула имеет какую-либо сложность в реализации от простой до сильной, и в каких-либо спецификациях так или иначе решалась, но важно было подойти к вопросу комплексно.

REST обязывает выполнять запросы на получение данных через GET, создание и обновление через POST/PUT/PATCH, удаление через DELETE. GraphQL же может нарушать это, так что нет, GQL — это не REST.

P.S. То что вы описываете как REST — всего лишь определение для Stateless (да, REST обязывает сервис быть stateles, но не ограничивается только этим).

На счёт преимуществ станадрта для подобных контрактов (Ваших decorators).

Вам достаточно привести пример REST апи запроса, когда один http-запрос должен возвращать:
1) 10 пользователей
2) Все доступные права
3) У каждого пользователя должны быть id + дата создания
4) Дата создания в формате RFC3339

Пример на gql:

{
    users(count: 10) { id, createdAt(format: RFC3339) }
    permissions { name }
}

Прошу заметить, что это всё ложится в стандартные возможности GQL и не требуют практически никакой документации, достаточно интроспекции типов. В отличие от вашего будущего примера на REST, который появится ниже в комментах (если появится =) ).