Дизайн GraphQL-схем - строим схемы правильно (версия 2) / Павел Черторогов (ps.kz)

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2019, Backend Conf
Тезисы и презентация:
backendconf.ru/...
GraphQL-схема может обернуться головой болью и кучей дополнительного кода для разработчиков. Поэтому, чем удобнее схема, тем быстрее, легче и с меньшим количеством ошибок будут разработаны ваши клиентские приложения.
...
--------
Нашли ошибку в видео? Пишите нам на [e-mail]

[@alex-0x6b]

5:40 - under_score потому что в представлении данных этот формат максимально безопасный и понятный. camelCase это уже про программирование. Не путайте.

[@xxxTSS]

интересно рассказывает

[@grommaks]

6:00 В SQL нет чувствительности к регистру символов underscore синтаксис дает гаратнии что это будет читаемо Большинство ORM идут по этому пути и навязывают такую нотацию в backend приложени... GQL активно живет и развивается 4ре года... SQL уже более 30 лет...по этому и underscore

[@nikitaproit]

Это не совсем правда, точнее совсем не правда, по следующим причинам: 1) В MSSQL можно управлять регистром имен кортежей, в MySQL вроде тоже(хотя разницы для SQL запросов не будет между upper и lower). Это что я помню. 2) Большинство ORM идут по пути предоставления мапинга названия поля в sql в название поля в коде. 3) Если ORM навязывает вам как называть переменные, вы пишите не самый чистый код. База данных конечно не просто деталь, но ORM это деталь, которая никак не должна сильно влиять на что-либо в приложении, тем более на имена переменных, тем более на формат данных вашего API. Прошло уже более 30 лет, а воз и ныне там. Underscore потому что файлы в линухе не чувствительны к регистру, однако если у вас есть конвенции имен, то "неожиданно" оказывается что конфликт имен после toUpper невозможен.

[@SbWereWolf]

@@nikitaproit в ORACLE имена приводятся к верхнему регистру и имена не могут быть больше 30-ти символов, ты когда получаешь из базы исходники объекта (таблицы, хранимки) ты видишь один раз как весь твой кэмэл кейс стал капиталайзед и читабельность стала равна нолю, после этого ты больше ни какой кемел кейс ни где в базах не используешь. Поэтому да, люди которые пишут для разных СУБД имеют такую профессиональную деформацию как именование объектов СУБД (колонки таблицы представления ключи констрейны) в снейк кейсе, потому что так спокойней, можно конечно имена таблиц и колонок писать в кавычках, и тогда можно даже пробелы вставлять и кириллицу, но так почему то ни кто не делает. В Laravel ORM Eloquent навязывает автоматическую конвертацию имён СУБД из снейк кейса в имена свойств в модели (PHP) в кемел кейсе, ORM навязывает имена геттеров и сеттеров для колонок, и как то живут люди. Laravel еси не первый то второй по популярности фреймворк.

[@nikitaproit]

​@@SbWereWolf вы бы ещё TypeORM в пример привели на ts. Нереализованная функциональность это не навязывание, это недоработка. В любом случае думаю реализация подобной функциональности на месте не непосильная задача, пару методов переопределить. Ну то что в ORACLE капиталайзед, не значит же что в коде все имена должны быть капиталайзед. Короче утверждение выше о том что "атата SQL underscore значит надо все писать underscore" это ересь, такая же ересь как делать в бд снейк кейс только потому, что в другой бд по другому нельзя. Если надо будет сменить бд, изменить названия колонок и 1 строчку конфига для ОРМ это не та проблема из-за которой стоит волноваться =) > и да, я знаю что апперкейс сравнивается быстрее, однако если код в паскаль/кемел кейс и бд их поддерживает, то мапинг вообще без преобразований будет однозначно быстрее