Правила именования полей и типов

GraphQL для проверки имен полей и типов использует следующую регулярку /[_A-Za-z][_0-9A-Za-z]*/. Согласно нее можно использовать camelCase, under_score, UpperCamelCase, CAPITALIZED_WITH_UNDERSCORES. Слава богу kebab-case ни в каком виде не поддерживается.

Так что же лучше выбрать для именования?

Абстрактно можно обратиться к исследованию Eye Tracking'а по camelCase и under_score. В этом исследовании явного фаворита не выявлено.

Коль исследования особо не помогло. Давайте будем разбираться в каждом конкретном случае.

Именование полей

Названиями полей активнее всего пользуются потребители GraphQL-апи, т.е. наши любымые клиенты — браузеры с JavaScript и разработчики мобильных приложений. Давайте посмотрим, что чаще всего используется по их конвенции для именования полей. Ведь если клиенты дергают ваше апи, то скорее всего они будут использовать ваше именование для переменных у себя в коде. Ведь маппить (алиасить) название полей в удобный формат не шибко интересная работа.

Согласно википедии следующие клиентские языки (потребители GraphQL апи) придерживаются следующих конвенций по именованию переменных:

JavaScript — camelCase

Java — camelCase

Swift — camelCase

Kotlin — camelCase

Конечно каждый у себя "на кухне" может использовать under_score. Но в среднем по больнице используется camelCase. Если найдете какое-нибудь исследование по процентовки использованию camelCase и under_score в том или ином языке программирования — дайте пожалуйста знать, очень тяжело гуглиться вся это тема. Кругом сплошной субъективизм.

А ещё, если залезть в кишки graphql и посмотреть его IntrospectionQuery, то он также написан используя camelCase.

Таким образом, чтоб удовлетворить большинство ваших клиентов по именованию полей:

Используйте camelCase для именования GraphQL-полей.

Именование типов

А вот именование типов, в отличии от полей уже происходит немного по другому.

В самом GraphQL уже есть стандартные скалярные типы String, Int, Boolean, Float. Они именуются через UpperCamelCase.

Также внутренние типы GraphQL-интроспекции __Type, __Field, __InputValue и пр. Именуются через UpperCamelCase с двумя андерскорами в начале.

А еще GraphQL статический типизированный язык запросов. И из GraphQL-запросов много кто генерирует тайп-дефинишены для статического анализа кода. Так вот если посмотреть как в JS именуют сложные типы во Flowtype и TypeScript — то тут тоже обычно используется UpperCamelCase.

Таким образом, чтоб не быть "белой вороной", быть понятным и удобным для большинства:

Используйте UpperCamelCase для именования GraphQL-типов.

Именование значений для Enum'ом

Enum в GraphQL используются для перечисления списка возможных значение у некого типа.

В самом GraphQL для интроспекции в типе __TypeKind используются следующие значения: SCALAR, OBJECT, INPUT_OBJECT, NON_NULL и другие. Т.е. используется CAPITALIZED_WITH_UNDERSCORES.

Если относиться к Enum-типу как к типу с набором констант. То в большинстве языков программирования константы именуются через CAPITALIZED_WITH_UNDERSCORES.

Также CAPITALIZED_WITH_UNDERSCORES будет хорошо смотреться в самих GraphQL-запросах, чтобы четко индетифицировать Enum'ы:

query { findUser(sort: ID_DESC) { id name } }

Опять таки дабы не расширять энтропию, надо быть как все:

Используйте CAPITALIZED_WITH_UNDERSCORES для именования значений ENUM-типов.

звучит логично

Поддерживаю

prisma/graphql-yoga v1.16.7 → v1.16.8 🎉

добавьте в бота хазуру чтоли)

А лучше ещё и changelog

и котиков ... ))

я кстати для таких вещей юзаю удобного бота)

Клёво, спасибо

кстати @nodkz я честно говоря согласен с высказываниями что именования переменых не самая животрепещущая тема, Климов в одном из своих видео сравневая flow  vs typescript назвал выбор  ts выбором хомяков 😊 без негатива, сразу пояснив что это для людей которым удоство и плюшки инфраструктуры порой важнее глубины возможнсотей саомй системы ))0

так вот, я яркий представитель племени хомяков ))) и уверен я не один такой

ты очень классно рассказывал про то как у вас все здорово натсроено

перегенерация всего и вс при старте

автодополнение благодоря  apollo-engine

проверка типов  и прочие плюшки

для меня это очень важные фишки  graphql

богатсво инфраструктуры которое которое частично позволяет снизить порог требовний к разработчикам и чуть меньше бояться кода джунов на большом проекте

это конечно звучит как наглость )) но нет ли в планах сделать обзор и ман по инфраструктуре  graphql ?