Тут точно не нужно [] к имени аргумента добавлять. Это противоречит спецификации. У вас IDE даже перестала голубым цветом подсвечивать это поле.

Нужно смотреть как работает директива @rest.

GraphQL + c# нормальная тема для бека?

А в чем проблема? Язык то не узкое место в реализации сервера, узкое место всегда одно - программист

Чисто интересно, я не для себя спрашиваю просто

Графкл это спека, язык не важен

👍

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

Это понятно, что в жс самое развитое

Вопрос то был не про либы а про спеку)

Вопрос был про GraphQL + c#. Просто сформулирован нечётко. )

Мне самому интерсно было бы увидеть сравнительную таблицу всяких либ на разных языках. )

Ну по той логике, что нужно работать с тем, где есть инструменты, значит мы все должны писать gql на scala. Только в sangria есть нормальный slowlog и нужные вещи для  анализа и оптимизации. В apollo за денюжку тоже многое есть, а некоторые и свои мидлвары пишут для анализа производительности. Поэтому все же узкое место всегда программист

Да, Sangria – крутая вещь. Многие идеи там были реализованы раньше других либ. Если мне не изменяет память, там даже deffer реализован, к которому JS только движется. Жаль, что Олега Ильенко больше нет с нами.

Для меня JS/TS – основной язык и меня в целом устраивает функционал GraphQL-либ для JS/TS.

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

В прошлом году Иван Гончаров, мейнтейнер graphql-js, немного поправил одну функцию и увеличил тем самым производительность в несколько раз.

Изначально библиотека graphql-js была написана для запуска в браузере как часть GraphiQL, и никто сильно не заморачивался о производительности. :)

В целом то производительности хватает за глаза, js очень легко масштабируется. В крайнем случае jit компиляция схемы сходу дает 20% производительности, но это и не нужно, БД всегда работает медленнее чем мап на мапе)

У меня в плане прод опыта RPS около 1000 спокойно на стандартном apollo server

В режиме кластера и авторизация по redis кешу, данных много и они разные. (приложение по записи путей с моб. телефона)

не могу задать вопрос, мои сообщения удаляются Почему ?

Тоже не понимаю этих танцев вокруг бэкэнд языка/фрэйморвка. Ещё ниразу в жизни не встречал проблемы из-за того, что условный express медленно распаковывает пакет. А вот из-за того, что БД не настроена/запрос фиговый/индекса не хватает/структура фиговая - кейсов немерено.