Холивар: Prisma, Join-monster, Hasura, Postgraphile

[nodkz]

Подводим итог общения с Максимом (api.fastcup.io):

• 3 человека воевали с GraphQL на бэкенде
• 30 моделей/табличек
• убито времени: — На призму 5 дней (Итог: просто охерел от того, насколько она популярна при ее днищенской функциональности) — На джоинмонстер 2 недели (Итог: join-monster тормозной) — На хазуру 3 дня (Итог: В хазуре все предельно ясно и понятно) — Переезд 1 неделя с join-monster на hasura (camelCase потеряли, underscore получили)

Disclaimer: Это субъективный опыт одной команды. Объективной оценки вам никто не даст. Кому-то Prisma, либо join-monster может зайти лучше чем Hasura.

---

Максим Макаров, телеграм @Maxpain177

[maxpain]

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

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

[nodkz]

Hasura

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

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

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

[nodkz]

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

Преамбула

Грамотно алтернуть таблицу, а потом шаманить АПИ - хасура. С Призмой миграции на порядок опаснее, особенно через 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 в бд. Но если очень нужно - то в призме есть интроспекция бд в схему (т.е. в призму импортируется схема существующей бд)

[Makazone]

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

[nodkz]

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

[ivan-kleshnin]

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

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