KN
Size: a a a
2018 May 23
KN
учитывая то, что всё есть и так
KN
без призмы
KN
только сабскрайберов пока что нет
KN
ну т.е. в том что я использую
ДР
только сабскрайберов пока что нет
было дело подсел на graphql-comopose , а когда дошел до реализации подписок, пришлось на Призму перейти)
KN
ну если задача исходит из бизнесовой, то да, призма тут вполне норм
KN
ну т.е. если надо сделать "вчера" и не хочется исследовать рынок. Я это имел ввиду
KN
На практике же всё что предлагает призма с прямым доступом к бд делается ровно в пару строчек кода
EF
На практике же всё что предлагает призма с прямым доступом к бд делается ровно в пару строчек кода
И генерация input типов для фильтрации?
KN
ну т.к. это минут за 5 делается же
KN
input Query {
orderBy: [String!]!
where: [Where!]!
take: Int
skip: Int
}
input Where {
field: String!
value: Any
op: Operation! = EQUAL
}
enum Operation {
EQUAL, ....
}KN
ну и маппинг:
input Query @in(action: "QueryInput@parse") { ... }public function parse(array $query)
{
$query = $this->repository; // Some repo
$query->orderBy(...$query['orderBy']);
...
return $query;
}
KN
и при указании этого инпута в резолвере аргументах на руках будет весь запрос, осталось смерджить его с текущим стейтом и всё
KN
@EugeneFedoseev если есть вопросы - спрашивай. Сразу замечу, что это решение, которое можно использовать в моём проекте, но не значит, что его нельзя перенести на какие-нибудь другие gql фреймворки
KN
Кстати, у меня есть предположение, что призма является идеальным решением, если разработчик знаком непосредственно с нодой, но не с другими бекенд языками, т.к. на Ruby, Java, PHP и проч. есть решения на порядок гибче, вроде JDBC или DBAL
a
имхо всё это работает ровно до тех пор пока приложение достаточно простое в плане бизнес-логики
a
как только бизнес-логика усложняется придётся переходить с призмы на решения которые позволяют более гибко управлять различными частями
KN
Ну фиг знает. Надо посмотреть на призму и вообще оценить в целом насколько решение гибкое и что-нибудь потырить
KN