Да, GraphQL не совсем _язык программирования_. В том смысле, что он декларативный, а не императивный.

и в скале пишешь сразу код и у тебя схема на лету генерится

хотя скала типизировнная

Я за то чтобы оба подхода были

Использовать тот который лучше подходит под задачу и команду

Но есть GQL template literal. Можно GraphQL на ходу генерировать с помощью JavaScript.

Зачем же всё фигачить на другом языке?

а это для парсинга квери, а не генерации)

Это как вместо CSS или HTML писать всё в JavaScript, а потом генерировать из него уже нормальный CSS или HTML.

Сейчас так и делается

😀

У CSS-in-JS, кстати куча противников.

Я посмотрел на этот код на Nexus и какая-то дичь. ) Я бы это не написал без подсматривания в доку. А вот на SDL пишу с закрытыми глазами.

тогда у тебя появляется проблема с поддержкой и sdl и твоих резолверов in sync up to date

Такой же синтаксис используется в библиотеке graphql-dotnet

Но мне она не нравится

Всем привет, расcказывали зачем и как мы используем GraphQL в нашем BAAS 8base https://www.youtube.com/watch?v=UAGsOxoKfbM&t=25s

👍

Граждане, а поделитесь пожалуйста:
1) в каких случаях вы не стали бы использовать graphql
2) когда обычный rest подходит больше
3) какие минусы существуют в использовании и разработке api на основе graphql

моё мнение (на все пунты сразу):
- когда и так всё устраивает
- когда лид против перехода на графкл
- когда нужно будет предоставлять api третьим лицам (гос. учреждения например), а там кроме как rest в лучшем случае ничего и не умеют больше
- когда нет времени вникать
- когда много работы с файлами (больше чем с текстовыми данными)
- когда на проект планируется брать джунов на поддержку (на рест они везде учились, а на графкл придётся учиться уже на проекте скорее всего
(+ ещё пару кейсов, но голова не варит ночью)

о, аналогию придумал пока писал, graphql - это как линукс, если нет рядом знакомого линуксоида. то лучше наверное и не переходить на него