Size: a a a

pro.rb (Ruby/Rails / RU)

2019 September 23

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
И в resolve методе резолвера отдаете хеш с руби типами и они сериалайзятся в графкл типы?

Я почему-то об этом не подумал 🙂
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
ага, резолвер отдает хеш с рубишными объектами, а потом по схеме дальше будет маппиться в нужные GraphQL типы. как только понял, что так можно — сразу вышел на новый уровень
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
А курсоры сами имплементили?
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
ага. за курсор можно прост принять айди какого-либо объекта. если коллекция упорядочена, то норм. так у нас и получилось)
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
но я щас думаю, что мб стоит потом влезть в Relay/прочие спецификации и не колхозить свои решения в будущем.

но мне не нравится возможность сделать запрос node и получить любой объект
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
Проблема в том, что для nodes я не нашел способа отдать резолвер - только тип (да, в нем уже могут быть резолверы на филды, но это опять же ближе к твоему способу)
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
я за то, чтоб типы ограничивали юзкейсы. т.е. заказы «в обработке» и завершенные заказы — в разных ручках. в идеале, в разных типах, но тут много сопротивления.
а релей как раз слишком много свободы даёт
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
🤔
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
Ну точнее я подумал что можно овверайдить nodes
и там типа find_reslover(arguments: arguments) но мне не хотелось так делать
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
Igor Morozov
я за то, чтоб типы ограничивали юзкейсы. т.е. заказы «в обработке» и завершенные заказы — в разных ручках. в идеале, в разных типах, но тут много сопротивления.
а релей как раз слишком много свободы даёт
а чем плохо orders(state: “state”) { } ?
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
тож норм, дело вкуса
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
я скорее против order(id: ID!). если желаемое состояние в каком-то виде передается — ок
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
а зчем вообще делают order(id:
почему на orders не сделать argument :id ?
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
Я делаю потому что это лучше описывает предметную область

С технической точки зрения:

1. если на клиенте юзать штуки типа Apollo, то возникает много вопросов с тем, как это в сторе будет храниться. Не инвалидирует ли это кеш orders с другими аргументами. Мб ещё какие-то проблемы, нужно просто изучить
2. mutually exclusive аргументы — штука сложная. у тебя появляется куча некорректных состояний, которые обязательно нужно обрабатывать.
из-за этого я полюбил типы-суммы и юзаю их вместо произведений
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
ну можно же возвращать массив из 1-го элемента 🙂
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
ага, и тут возникают те самые вопросы с кешом и что произойдёт с предыдущими массивами из N элементов
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
и с метаданными
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
Я понял идею, просто нужно сначала изучить, как Apollo и прочие клиенты будут себя вести при таком поведении. Не хочется бороться с инструментами, особенно когда они за тебя стейт менеджат
источник

NP

Nicolae Paraschiva in pro.rb (Ruby/Rails / RU)
А у вас не было такого прикола, что после рейза ошибки в графкл, рельсы начинают жрать 99% процессора и следующий реквест зависает?
источник

IM

Igor Morozov in pro.rb (Ruby/Rails / RU)
о_О
источник