Эх, а я думал вжух и пью чай уже

Про печеньки не забудь

не, толстым буду

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

Да даже не из за зависимостей, а из за лени.

Рецептов пока очень мало, и надо все ставить ручками, а половина и в композере зависимости от 4 не прописали

ну еще оч рано обновляться

подожду к весне)

https://packagist.org/packages/jolicode/gif-exception-bundle топовый пакет

$count = 2 ** 9;

если тут есть люди у которых есть опыт с symfony + graphql - хочу фидбэк. В частности "боль" с которой вы сталкнулись.

пока в списке только "как удобно делать пагинацию"

если тут есть люди у которых есть опыт с symfony + graphql - хочу фидбэк. В частности "боль" с которой вы сталкнулись.

Очень небольшой, но есть

накидывай на вентилятор

пока в списке только "как удобно делать пагинацию"

На это убил минут 30, но не сказал бы что это прям очень сложно

накидывай на вентилятор

Да все норм, по сравнению с РЕСТ )

На это убил минут 30, но не сказал бы что это прям очень сложно

речь не о сложно а о удобно и естественно)

интересуют неудобные моменты, кастыли... ну и все такое

что-то что типично но делается не за 5 минут а за те же 30 как случай с пагинацией

речь не о сложно а о удобно и естественно)

А что такое удобно и естественно, я все это мог обернуть в 1 файл, и было бы удобно и естественно)

А что такое удобно и естественно, я все это мог обернуть в 1 файл, и было бы удобно и естественно)

в краткосрочной перспективе. Давай серьезно

p.s. с relay юзал или без?

что-то что типично но делается не за 5 минут а за те же 30 как случай с пагинацией

Слушай, но в РЕСТ паджинация тоже не за 5 минут делается, если только ты не ставишь дикий кухонный комбайн. Если по факту то особых проблем небыло, с n+1 особо не парился, так как есть идмап, но если нормально все делать то это действительно может несколько осложнить работу

p.s. с relay юзал или без?

без

Слушай, но в РЕСТ паджинация тоже не за 5 минут делается, если только ты не ставишь дикий кухонный комбайн. Если по факту то особых проблем небыло, с n+1 особо не парился, так как есть идмап, но если нормально все делать то это действительно может несколько осложнить работу

простая пагинация с курсором делается за 5 минут

без всяких там комбайнов

@fes0r Я бы сказал что сейчас основная проблемма в отсутствие адекватных либ

@fes0r Я бы сказал что сейчас основная проблемма в отсутствие адекватных либ

меня фидбэк именно по ним и интересует))

что было неудобно, что бы "хотелось по другому"

простая пагинация с курсором делается за 5 минут

У тебя есть паджинатор который вернет всю инфу в читаемом ввиде сразу?

У тебя есть паджинатор который вернет всю инфу в читаемом ввиде сразу?

что-то типа того

меня фидбэк именно по ним и интересует))

Ну смотри, есть бандл для симфони, он как бы говно именно для меня потому что я не люблю упарываться писать все в yml, а там все в yml

но давай по либкам, подходы сравнивать не надо

что-то типа того

и ты его сам написал? верно?

и ты его сам написал? верно?

это просто надстройка над fractal

Ну смотри, есть бандл для симфони, он как бы говно именно для меня потому что я не люблю упарываться писать все в yml, а там все в yml

да, но есть type language так что в целом в yaml необходимости нет

и конкретно этот бандл шлак, а ешидо я не доверяю (хотя пол года назад он был очень интересен)

но давай по либкам, подходы сравнивать не надо

Есть еще 2 либы для графа (То что у Кирила пока в расчет не берем), это вебоникс и ешидо

я просто сейчас просто юзаю webonyx/graphql-php

Ешидо почти не развиваются сейчас, но я использовал их, и у них более приятное апи

А вебпак имеет ужасное апи, как будто слизаное в ноды

webonyx внутри дикое говнище

но работает

а эта хрень мертва? https://github.com/overblog/GraphQLBundle

А вебпак имеет ужасное апи, как будто слизаное в ноды

ну типа так и есть, они даже не отрицают

То есть все в массиве, и там колбеки, если бить по файлам, о там все равно массивы, короче дичь

То есть все в массиве, и там колбеки, если бить по файлам, о там все равно массивы, короче дичь

я короч сейчас взял этот самый вэбоникс и тупо сделал глобальный ресолвер (типа дефолтный) + запилил компайл пасс который конфигурит к схеме ресолверы из моих сервисов

типа схема отдельно, имплементация схемы отдельно

Ну так вот в том и речь что сейчас хочется выбрать чтото одно, и хорошее, это либо type lang, либо хорошая ооп либа.

в целом весьма удобно и не надо в клиетском коде юзать это убогое API

Ну так вот в том и речь что сейчас хочется выбрать чтото одно, и хорошее, это либо type lang, либо хорошая ооп либа.

как по мне нет смысла смотреть куда-либо кроме как на type lang

хотя тебе так или иначе придется кастомные типы дефайнить

дайте чет почитать по тайпланг или хотя бы запрос в гугл

но давай более предметно поговорим... представь что у вэбоникс нормальное API

дайте чет почитать по тайпланг или хотя бы запрос в гугл

graphql type language, ваш капитан очевидность

первого слова мне не хватило спасибо, кэп)

как по мне нет смысла смотреть куда-либо кроме как на type lang

Тут я бы сказал все зависит от построения самого АПИ, ну и скорости перехода, у меня сейчас джесон апи, и у меня есть под каждый тип свой файл, со своей схемой (Чтото похожее на фрактал), и у меня переезд занял был 1-2 дня, а вот с тайп ленг могут быть траблы с резолвами, если у тебя определенное поле резолвится както иначе как все остальные поля

Тут я бы сказал все зависит от построения самого АПИ, ну и скорости перехода, у меня сейчас джесон апи, и у меня есть под каждый тип свой файл, со своей схемой (Чтото похожее на фрактал), и у меня переезд занял был 1-2 дня, а вот с тайп ленг могут быть траблы с резолвами, если у тебя определенное поле резолвится както иначе как все остальные поля

ну мне переезжать не нужно.

так что давай упростим до гринфилд проектов

Но на самом деле эта не особо проблемма, но опять же, было бы не плохо чтобы из тайп ленг, собирались резолверы или типа того

Но на самом деле эта не особо проблемма, но опять же, было бы не плохо чтобы из тайп ленг, собирались резолверы или типа того

вооот, подходишь к сути вопроса

я чего пока не могу понять....

вот есть у тебя юзер и есть коллекция юзеров. Это будут два ресолвера. Что должен вернуть ресолвер для коллекции? кто будет из юзеров данные доставать?

вот есть у тебя юзер и есть коллекция юзеров. Это будут два ресолвера. Что должен вернуть ресолвер для коллекции? кто будет из юзеров данные доставать?

Ну давай разделим все на 2 типа, 1 достает данные, второй их преобразует

я просто чет в webonyx этот момент не могу раскопать, будет ли он по элементам коллекции ходить и ресолвить типы

Ну давай разделим все на 2 типа, 1 достает данные, второй их преобразует

да, мне так и надо)

И получается что ты можешь дастать в резолвере колекций, а пробразовать через схему юзеров

как удобнее по твоему дефайнить ресолверы?

я просто чет в webonyx этот момент не могу раскопать, будет ли он по элементам коллекции ходить и ресолвить типы

хз, в юшидо норм

ERROR: S client not available

у меня пока есть два варианта - ресолв по типу и ресолв по пути до филда

у филда приоритет выше

ресолфер филда уже будет инициировать ресолверы для типов

исходя из возвращаемых типов

у меня пока есть два варианта - ресолв по типу и ресолв по пути до филда

Ну по типу тоже есть косяк, водь я могу вызвать допустим букинги из коря, а могу от дома, и там все будет доставаться как минимум по разному

Ну по типу тоже есть косяк, водь я могу вызвать допустим букинги из коря, а могу от дома, и там все будет доставаться как минимум по разному

доставать будут ресолверы филдов

Ну да, ты вроде логично описал

а когда у тебя уже получены букинги то в целом все единообразно, либо это будут разные типы

Они и будут)

Но в целом все это преобразовывать может 1 отдельный класс

в идеале что я хочу - запилил файлик со схемой, запилил нэймспейиск с ресолверами (которые как контроллеры по своей сути но сервисы)

аннотациями/тэгами к сервисам замэпил кто что должен ресолвить

провалидировал что для всего есть ресолверы и мы ничего не упустили

вжух и в дамки, что бы вообще не соприкасаться с webonix api но пользоваться всеми благами

в идеале что я хочу - запилил файлик со схемой, запилил нэймспейиск с ресолверами (которые как контроллеры по своей сути но сервисы)

Ручками все жто делать предлагаешь*?

Ручками все жто делать предлагаешь*?

файлик со схемой - да. Сервисы-ресолверы - а что тут можно не ручками делать? Если ты выплюнул готоый массив или объект - то дефолтный ресолвер подхватит

или ты о чем?

вжух и в дамки, что бы вообще не соприкасаться с webonix api но пользоваться всеми благами

Знаешь что меня еще немного беспокоет, мы же можем выбирать любые поля, и у нас есть поле допустим row_image, где мы выдаем код картинки, ну и делать нам это каждый раз соврешнно не хочется, нужна возможность резолвить отдельное поле, но лучше чтоб это было акурат в том же файле где и сам тип

файлик со схемой - да. Сервисы-ресолверы - а что тут можно не ручками делать? Если ты выплюнул готоый массив или объект - то дефолтный ресолвер подхватит

Ну ты часто к доктрине модели ручками делаешь? А миграции?

файлик со схемой - да. Сервисы-ресолверы - а что тут можно не ручками делать? Если ты выплюнул готоый массив или объект - то дефолтный ресолвер подхватит

Я бы хотел чтобы классы (под тип фракталовских) и тд сразу создали исходясь из моих типов допустим

Знаешь что меня еще немного беспокоет, мы же можем выбирать любые поля, и у нас есть поле допустим row_image, где мы выдаем код картинки, ну и делать нам это каждый раз соврешнно не хочется, нужна возможность резолвить отдельное поле, но лучше чтоб это было акурат в том же файле где и сам тип

ресолвер = метод сервиса, можешь хоть всю апи в одном файле заимплементить

или ты о чем?

Для функций которые чтото создают можно допустим инвокбл классы, а там уже сам подключай что хочешь, и возвращяй как хочешь

Ну ты часто к доктрине модели ручками делаешь? А миграции?

ммм... модели - всегда, миграции - очень часто тот DDL который она генерит меня не устраивает.

p.s. мои доктрин сущности возможно несколько отличаются от потребностей большинства))

ресолвер = метод сервиса, можешь хоть всю апи в одном файле заимплементить

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

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

в каком месте завязка?

p.s. мои доктрин сущности возможно несколько отличаются от потребностей большинства))

Знаю знаю)

в каком месте завязка?

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

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

эти сервисы как бы UI layer, им норм знать о графе

если им это надо

в большинстве случаев тебе это не надо

тебе сразу готовые аргументы передадут, и все такое