[ARCHIVED] Где должен лежать api?

[carina-akaia]

Стоит ли вообще api/ конкретного домена держать в каталоге этого домена?
Может лучше вообще все методы складывать в /shared/api/?

Если понадобится вызвать api метод, который обычно был нужен только в одном домене, из другого домена, то на первый взгляд его можно просто импортировать. Но в таком случае порождается зависимость доменов друг от друга.
А если один и тот же метод нужен больше чем в двух доменах -- то возникает срочная необходимость вынесения его в /shared/

Source

It depends on your app

Моё мнение: данная степень свободы создаёт риск столкнуться с проблемами, описанными выше, поэтому имеет смысл в рамках методологии задать строгое правило по организации методов взаимодействия с api только на верхнем уровне.

Что же касается GraphQL queries -- это по сути не методы доступа к api, а модели, к тому же, привязанные к конкретным юзкейсам, так что не думаю что имеет хоть какой-то смысл говорить о них в данном контексте.

[ilyaagarkov]

напрямую связано с #14. Я бы даже сказал что это один и тот же вопрос.
Решая его, решаем и этот.
Есть ли смысл для слоя api делать другие правила?

[azinit]

@ilyaagarkov я вот тоже этим вопросом задавался сначала)

Но как показал опыт - если пробовать делать еще для каждого модуля (feature/entity/...) - локально свой api, то приводит в большим проблемам чаще всего)

Когда еще есть работа с кешированием запросов (GraphQL, react-query) - вродь еще не так критично если api может лежать рядом с местом использования, хотя все равно не хочется дублировать логику запросов в модулях

Но чаще всего - у нас обычный REST + state-manager...

Учитывая все это, и плюс то, что иногда бывает прям жизнено необходимо проксировать и контролировать доступ ко всем инстансам API (в последнее время у меня примерно похожее по работе) - проще рил реализовывать это все на уровне shared/api, чтобы был "один источник истины", к которому обращались все вышележащие модули (feature/entity/...)

[azinit]

Возможно, методологией мы прямо запрещать такое и не будем, но с точки зрения рекомендации - будем скорее всего настаивать на инстанциировании API в shared

Хотя увы и да - это не оч сходится мыслью "любой {ABSTRACTION-TYPE} может быть внутри любой {ABSTRACTION-FEATURE} - по необходимости"

[pleshevskiy]

но погодите, господа

shared - переиспользуемый код, не имеющий отношения к специфике приложения/бизнеса.

Тоесть мы в идеале можем просто скопировать эту папочку в новый проект, если мы хотим построить его на тех же принципах. API как мне кажется очень специфично к приложению/бизнесу и то, что мы должны будем в новом проекте удалить эту папочку сразу не разбираясь уже наводит на мысль. Даже не говоря о том, что API уже должно возвращать бизнес-сущности, а они у нас располагаются в entities. Тут мы нарушаем второй принцип методолгии

Слои стандартизированы во всех проектах и расположены вертикально. Модули на одном слое могут взаимодействовать лишь с модулями, находящимися на слоях строго ниже.

[nazamov]

Привет! А с какими проблемами вы сталкивались точнее и детально плиз? Это очень важный момент.

[MalSolt]

я думаю должно быть 2 части api. Есть api общие, где мы после вызовы не ожидаем что-либо положить в стейт глобальный, а есть те, которые мы после вызова еще что-то ложим в стейт, допустим любой гет запрос. Мне кажется, что запросы привязанные к какой-то конкретной части стора, должны хранится именно рядом с этим стором, допустим есть стора users, и любой users запрос хранится рядом с этим стором, ну кроме некоторых пост запросов, результат которых не важен в самом сторе, а просто нужна какая-та всплывашка, допустим "документ отправлен успешно"

[mnik01]

Почему обсуждение архивировано? Кажется, к консесусу так и не пришли.