Холивар: Prisma, Join-monster, Hasura, Postgraphile about conf-talks HOT 6 OPEN

Добавлю про переезд с jm на хазуру.
Виртуальные поля в jm были в виде указания sqlDeps, а graphql-tools позволяют сделать тоже самое с помощью передачи fragmentа в одной из схем, передаваемых в mergeSchemas. Также мы избавились от кучи аггрегаций, sql-запросы которых мы писали прямо в резолверах, эта функциональность из коробки есть в хазуре. В мутациях мы возвращали объекты с помощью jm resolvera, будто это обычный query, в случае с хазурой заменили это с помощью delegateToSchema

В jm нужно самому везде прописывать проверку на видимость полей определенному юзеру/роли. В хазуре же все из коробки с помощью permissions.

from conf-talks.

Hasura

а у тебя не возникало задачи скрыть поля типа "password" ?

Вот так можно для определенной роли настроить "видимость" полей

Если нужно поле показывать только для текущего юзера, нужно в pg создать view users_private. Куда поместить поля, которые нужно только для текущего юзера и/или админа показывать. Вот так можно настроить видимость сообщений для чата, если у него allow_read = true или если ты есть в chat_permissions

from conf-talks.

Призма редактирование полей

Преамбула

Грамотно алтернуть таблицу, а потом шаманить АПИ - хасура. С Призмой миграции на порядок опаснее, особенно через SDL.

Ответ от @uxname:

дополню свой ответ опять) в призме крайне офигенная система миграции, мне очень понравилась

Скринкаст изменений (6:42)
https://youtu.be/6v75XJtAhCs

Вопросы по изменению существующего поля (понятно что у них там мелки баг, но очень неприятный)

1. Сейчас по ФАКТУ у тебя в базе удалилось поле аватар или там два поля теперь - аватар и фото?

Осталось одно поле, avatar переименовалось в photo

2. Изменение типа поля как происходит? Например строка в число (и часть значений у тебя буквы, а другая часть записей с цифпвми в виде текста).

Если данные уже есть в бд (т.е. нарушается констрейнт) - то только через флаг --force, который удалит весь столбец, а если столбец пустой - то просто пересоздаст его (удалит и создаст новый, с новым типом)

Changes:
  User (Type)
  ~ Updated field `string_int`

3.1) Если поле уже существует в базе. К примеру я его как-то хитро через скрипты свои создал и заполнил числами. Как поведет себя призма когда при создании поля Int, наткнется на уже существующее поле Int.

3.2) Что сделает призма если поле Int уже есть, но оно ее просят создать поле String с тем же именем. Рыгнется или сконвернирует данные?

3.1, 3.2) Коротко: так лучше не делать, будет работать через раз, например если создать поле с другим типом - напишет что всё ок (на самом деле тип в бд останется старый), если после этого поменять тип на другой (через призму) - напишет что всё ок, а если после этого опять через призму поменять обратно на другой тип - ругнётся. Лучше в обход призмы в бд не лезть создавать что-нибудь, такие таблицы лучше создавать в отдельной schema в бд. Но если очень нужно - то в призме есть интроспекция бд в схему (т.е. в призму импортируется схема существующей бд)

from conf-talks.

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

from conf-talks.

Новый игрок в полку
https://www.graphile.org/postgraphile/

from conf-talks.

Попытался категоризировать современные инструменты и сервисы, связанные с GraphQL:

https://github.com/ivan-kleshnin/backends

from conf-talks.