У меня к примеру, в апи что я сейчас делаю - рест и gql, живут совместно, для различных клиентов. Так вот именно связь с бд и получение данных, я вообще вынес в отдельные сервисы, в случае рест контроллеры у меня являются валидаторами и не более, в случае gql также. Абстрагируйте по максимуму логику

Пишу graphql–бэкэнды на Ruby, все хорошо 😺

я тоже на руби и тоже всё хорошо 🙂

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

как на используемом apollo client добавить header в контексте ?

да, у меня так сделано, но надо перезагружать страницу (создается new ApolloClient),
а в тот который создан уже как-нибудь можно уже добавить?
что-то не могу найти

типо client.header(....)

Через apollo-link-context https://www.apollographql.com/docs/link/links/context/#Usage

спасибо

@nodkz дай пожалуйста бест практиз из личного опыта, как лучше в схеме описать подобное:

Нужно забирать сущность по определённым полям, которые всегда уникальные. Пусть будет условный page и нам надо дать в схеме возможность забрать страницу по её id и пусть будет path, оба поля уникальные. Я вижу таие варианты:

1. Сделать отдельные ручки вроде page и pageByPath и соответственно дать сделать аргументы id и path обязательными для кажого Query. Не навится, потому что плодим Queries.

2. Сделать отдельную ручку вроде page и в ней два аргумента id и path. Плохо, потому что аргументы придётся делать необязательными и валидировать вне схемы.

Что-то ещё?

Коллеги, подскажите, пожалуйста, как лучше писать интеграционные тесты? BFF дело ответственное. Или лучше e2e интерфейсы тестить?

Что такое Дизайн. Это решение какой-либо задачи в удобной и простой форме.

Какой сделать дизайн графкуэль схемы?
Это зависит от твоих клиентов – как им будет удобнее всего потреблять твою схему. Надо дать так, чтоб удобно было взять.

Оба твоих варианта годны. Еще лучше если оба реализуешь 😅

type Query {
 pageById(id: Int!): Page
 pageByPath(path: String!): Page
 page(filter: PageFilter!): Page
}

type PageFilter {
 id: Int
 path: String
 pathRegexp: String
 pathStartsWith: String
 pathEndsWith: String
}

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

пользователю будет сложно выбрать когда много вариантов)

Я бы оставил только page(filter: PageFilter!): Page как самый универсальный, filter переименовал бы в where.

И только не type PageFilter, а input PageFilter.

А когда завезут union input будет легко мигрировать.

В Prisma как раз такой дизайн.

Спасибо за развёрнутый ответ. А мы разве не попадаем с фильтром на такой проблеме, что если PageFilter обязательный, то вложенные поля должны быть необязательными, а значит можно отправить запрос с пустым PageFilter

Да, конечно я могу НЕ на уровне схемы обработать ошибку, но это делает схему менее строгой

Если у тебя PageFilter обязательный, то тебе вроде придётся хоть одно из полей PageFilter обязательно передать.

иначе PageFilter будет null