Для этого умные дядьки давным давно придумали unit of work — запрос к бд будет один. Я очень ответственно подхожу к вопросу лишних запросов.
Я думал о предложенном вами варианте. Но это порождает запросы с неопределенной структурой — в вашем варианте в onlyFields можно передавать что угодно. Ну или как минимум, завести какой-то Enum с перечислением всех полей доступных в данной сущности.
onlyFields: [ExampleInputField!]
В общем, этот вариант будет работать, но он мне субъективно не нравится.
Потому что у нас получается два источника истины: один — это список полей самой сущности, второй — это Enum перечисляющий поля.
Оу, простите, виноват. Я почему-то подумал, что это про второй вариант.
Также непонятно, если у вас CRUD, и на каждую сущность форма со всеми полями, зачем отправлять только часть из них, если у вас на руках полная модель.
Чтобы реализовать концепцию partial update — отправлять только то, что было изменено. Прошу вас, потерпите немного. Иначе мне придется выложить все свои соображения по этому поводу в комментариях, а потом написать пост единственным содержимым которого будут ссылки на эти комментарии )
Вызвать какую мутацию? У вас их две. А с ростом количества полей, их количество также будет расти. Подождите немного, я подробно разберу эту тему, в одном из следующих материалов (я пока не решил какая из тем пойдет вперед — народ сильно топит за "разграничение доступа").
Главным образом, потому что хотелось единожды написать API под всех возможных потребителей. В случае с OpenAPI/JSON-API и проч. пришлось бы заниматься поддержкой нескольких разных схем для разных потребителей.
Сама схема (почти полностью) пишется руками, из нее генерируется рефлексия схемы (railt/sdl), потом рефлексия проворачивается через мясорубку редюсеров, которые накидывают свои навороты (в том числе, там обрабатываются пользовательские директивы серверной стороны), и в итоге всё это маппится на схему типов webonyx. Получившаяся схема-webonyx закидывается в исполнитель-webonyx, который уже обрабатывает пользовательские запросы согласно схеме.
Допустим, как вы и сказали, я хочу отправлять только часть полей. При этом, если они переданы, то они не должны быть null. Как описать эту ситуацию в системе типов GraphqQL?
Думаю, что стоит сделать небольшую ремарку относительно того, где я применяю данный язык. Это довольно сложная SPA-админка, большая часть операций в которой — это довольно нетривиальный CRUD(сложновложенные сущности). Значительная часть аргументации в данном материале связана именно с характером приложения и характером обрабатываемых данных. В приложениях другого типа (или с другим характером данных) таких проблем может и не возникнуть в принципе.
Вы не можете выкинуть CRUD из статьи о CRUD.
Умоляю: сжальтесь надо мной и прочитайте материал.
В таком случае, под проблему в дизайне API можно вообще подвести любой тезис из статьи )
Немного оффтоп, но мне это напоминает, ситуацию, которая сложилась у меня с поддрежкой Razer.
Была у меня клава с макросами. И решил я запилить макрос, который раз в час жмякает пару кнопок. Есть там такая модель макроса: нажал один раз — включил макрос, нажал второй — выключил. Но вот жеж косяк — если ты запустил макрос, то хотябы один раз он должен отработать. Нельзя отключить макрос до завершения текущей итерации и даже профиль переключить нельзя, пока макрос не завершен. И я, как программист, понимаю в чем проблема. Но мне, как пользователю, нужен функционал. Я написал в поддержку (ну, думаю, может в следующем патче на по поправят косяк). Описал суть проблемы с такими макросами, они очень долго не могли понять, что именно мне не нравится (тут, возможно, виноват мой не очень высокий скилл в заморском наречии). Потом они наконец сообразили в чем косяк, и сказали мне: "Не пишите такие макросы". А потом закрыли тикет. Заплатки на это дело нет по сей день.
Так вот к чему это я… всегда можно сказать "не делай так". Вот только проблема от этого не исчезнет )
Расскажите, в каком языке описания данных есть полиморфизм и дженерики, неймспейсы.
Я не могу вспомнить язык с полиморфизм и дженериками, который не подходил бы для описания данных. Другое дело, что они еще и исполнятся могут, но это совсем другая история.
А что дальше, лямбда-функции, циклы, условия?
А вот это уже рантайм. Но вообще-то без привязки лямбд, к полям типов у вас и приложение работать не будет...
Зачем вообще тогда выдумывать и использовать декларативные языки и форматы, если можно просто взять любой готовый язык общего назначения и написать для него, к примеру, еще один компилятор?
А вот это мысль кстати. Взять только декларативную часть от какого-то языка, выкинуть весь рантайм — возможно получится недурной язык описания схемы данных.
Почему все это становится недостатками GraphQL — абсолютно непонятно.
Я уж как мог так объяснил. Не знаю как сделать, чтобы вам было понятно.
Что не так с JSON
Я в этой статье написал, что не так с JSON. Читайте уже материал )
Я изложил конкретно недостатки системы типов языка GraphQL, с моей точки зрения.
1. Null
1.1 Вывернутые наизнанку монады.
1.2 Неоднозначность nullable при вводе.
2 Неудобное разделение ввода и вывода.
3 Отсутствие полиморфизма при вводе.
4 Отсутствие дженериков.
5 Отсутствие неймспейсов.
Прочитайте наконец материал, чтобы не приходилось в комментариях спрашивать автора о чем материал. Ну это уже просто неуважение какое-то (
Для этого умные дядьки давным давно придумали unit of work — запрос к бд будет один. Я очень ответственно подхожу к вопросу лишних запросов.
Я думал о предложенном вами варианте. Но это порождает запросы с неопределенной структурой — в вашем варианте в onlyFields можно передавать что угодно. Ну или как минимум, завести какой-то Enum с перечислением всех полей доступных в данной сущности.
В общем, этот вариант будет работать, но он мне субъективно не нравится.
Потому что у нас получается два источника истины: один — это список полей самой сущности, второй — это Enum перечисляющий поля.
Или можно просто взять GraphQL )
Хотел статью написать, а теперь придется в Доту играть (
Оу, простите, виноват. Я почему-то подумал, что это про второй вариант.
Чтобы реализовать концепцию
partial update— отправлять только то, что было изменено. Прошу вас, потерпите немного. Иначе мне придется выложить все свои соображения по этому поводу в комментариях, а потом написать пост единственным содержимым которого будут ссылки на эти комментарии )Вызвать какую мутацию? У вас их две. А с ростом количества полей, их количество также будет расти. Подождите немного, я подробно разберу эту тему, в одном из следующих материалов (я пока не решил какая из тем пойдет вперед — народ сильно топит за "разграничение доступа").
Именно так. Только не "либо ставите" null, а "либо устанавливается дефолтное значение".
Например вот так:
И, что бы это поведение работало парвильно, нужно расценивать вот это выражение:
как
Но тогда косяк в том, что концепция partial input просто перестает работать.
Другими словами, я не считаю понятия
undefinedиnullтождественными.Если кому-то и так норм — я рад за них, мне — не норм.
это не точно )
Вообще, эта нормальная идея. Никто ж не против.
Допустим, как вы и сказали, я хочу отправлять только часть полей. При этом, если они переданы, то они не должны быть null. Как описать эту ситуацию в системе типов GraphqQL?
Я просто процитирую сам себя:
Вы не можете выкинуть CRUD из статьи о CRUD.
Умоляю: сжальтесь надо мной и прочитайте материал.
В таком случае, под проблему в дизайне API можно вообще подвести любой тезис из статьи )
Немного оффтоп, но мне это напоминает, ситуацию, которая сложилась у меня с поддрежкой Razer.
Так вот к чему это я… всегда можно сказать "не делай так". Вот только проблема от этого не исчезнет )
Только вот маппить это всё равно придется на имеющуюся систему типов.
Я так и сказал.
Куда делась неоднозначность? Всё верно — никуда.
Я не могу вспомнить язык с полиморфизм и дженериками, который не подходил бы для описания данных. Другое дело, что они еще и исполнятся могут, но это совсем другая история.
А вот это уже рантайм. Но вообще-то без привязки лямбд, к полям типов у вас и приложение работать не будет...
А вот это мысль кстати. Взять только декларативную часть от какого-то языка, выкинуть весь рантайм — возможно получится недурной язык описания схемы данных.
Я уж как мог так объяснил. Не знаю как сделать, чтобы вам было понятно.
Я в этой статье написал, что не так с JSON. Читайте уже материал )
В HTML c полиморфизмом вообще-то всё ок )
1. Null
1.1 Вывернутые наизнанку монады.
1.2 Неоднозначность nullable при вводе.
2 Неудобное разделение ввода и вывода.
3 Отсутствие полиморфизма при вводе.
4 Отсутствие дженериков.
5 Отсутствие неймспейсов.
Прочитайте наконец материал, чтобы не приходилось в комментариях спрашивать автора о чем материал. Ну это уже просто неуважение какое-то (