Или а как кешировать данные, у меня же один эндпоинт и всё в виде POST-запросов? ))

- Замедляет паралельную работу. Пока backend не напишет резолверы и описания ко всем полям - front не сможет сгенерировать TS/замокать/ для работы с бизнес сущностями.
- Если мы имеем сложный экран то при правильном подходе на разборе задачи мы фиксируем схему которая устроит и фронт и бек. В случае code-first она хранится в лучшем случае где-то в Jira/Slack/Cofluence etc и не гарантирует вообще ничего + моментально устаревает. Опечатки тоже не исключает. В случае schema first и back и front ГАРАНТИРОВАНО согласованы
- Если back случайно сделает опечатку в существующем поле - ошибки не будет тк он источник правды, а не схема. В лучшем случае на CI проверках что-то ругнется. В худшем - упадет уже после MR если авто проверок нет. В особенности если нет TS или api тестов - тогда точно упадет.
- Нет возможности прокинуть в схему комментарии к полям (которые в свою очереди может подхватить генератор TS типов). Возможно это изменилось и не актуально.

Читать и изучать надо будет много. )

А ещё ракеты падают

Как говорит Павел вы одним этим все не решите

да, все недостатки GraphQL я уже разузнал заочно, спасибо.

Но эти пункты опять таки относятся к проектам средним и крупным. В MVP где работает 1.5 земплекопа это не критично

Там где нужно гибко, огонь

Да, это реальные недостатки, которые поважнее будут чем отсутствие спеки 👍😄

Там где жёстко и предсказуемо можно и в рест

С любой технологией так

Что мешает на code-first накидать модели без резолверов или моки вместо резолверов?

Лень)

Ответте еще на один вопрос плис: файлы с расширением .graphql это Apollo c  Prisma придумали? (Не видел об этом на graphql.org и у graphql-js)

Я так делаю, сначала пишу мок, а дальше агрегации в монге )

Конкретно само расширение файлов неважно, это может быть и .gql

Парень педант, оказалось)

Тут ещё нюанс в том, что GraphQL – это 2 разных языка – SDL для описания схемы на сервере и QL – для описания запросов на клиенте.

И в файлах с расширением .graphql может быть как первое, так и второе. )

По ходу мы его запутаем

Во-первых это не решает всех указанных пунктов - только возможность паралельной работы.

Во-вторых это не гарантирует правильность возвращаемого типа данных - если ты готовишь очень волосатый обьект с 0 то легко ошибиться - тебе надо все время глазами матчить то, что вы запланировали с тем, что ты пишешь.

В третьих это все здорово в идеальном мире.  А в мире где graphql бывает на Java да еще с резловерами которые имеют сложные кастомные агрегаторы без даталоадеров это превращается в совсем сложную задачу порой