@graphql_ru
GraphQL — русскоговорящее сообщество

Общаемся на темы, посвященные GraphQL и опыту его использования. Проблемы. Новости. Решения. Вам могут быть полезны: @apollo_ru, @react_js, @vuejs_ru Рекомендуем сразу отключить уведомления, чтобы пребывание в чате было полезным и комфортным.

352 members

Архив канала @graphql_ru 31 января 2018 г.

11:12:29 ДП
User 371133717
User 228403837
это был бы void и да его нет
11:13:45 ДП
User 228403837
User 371133717
покажи мне место в спеке graphql
11:14:07 ДП
User 228403837
я тоже могу скалярных типов своих нахерачить и закрыть этот вопрос)
11:14:27 ДП
User 371133717
Я таким образом закрыл, просто поделился.
12:04:24 ПП
User 128597654
User 228403837
в идеале я бы хотел возможность совершать последовательность действий в духе....

mutation -> query
refetchQueries не подходит для вашего кейса?
12:05:02 ПП
User 228403837
User 128597654
refetchQueries не подходит для вашего кейса?
я не юзаю аполло пока-что
12:05:09 ПП
User 228403837
ну и выглядит это как кастыль
12:06:02 ПП
User 228403837
я больше с позиции бэкэнда рассуждаю, мне выгодно на бэке полностью разделять операции записи и чтения. Ну и вообще - CQS не просто так придумали
12:06:27 ПП
User 128597654
аа, понял
12:24:35 ПП
User 128597654
Если в приложение есть лента уведомлений для пользователя, которая формируется из 6+ разных состояний, то как обычно делают

- Создают отдельную таблицу с типами уведомлений, референсами, информацией о просмотре уведомления.
- Делают query по 3-4 таблицам с необходими условиями и отдельно хранят информацию о просмотре.

Как вам кажется лучше, практичнее и масштабируемее, коллеги?
12:25:06 ПП
User 228403837
первый вариант и событийная модель
12:25:17 ПП
User 228403837
нотификации отдельно, тригеры нотификаций отдельно
12:25:35 ПП
User 228403837
потом будет проще делать всякие истории нотификашек, дайгесты и прочую дрянь
12:25:41 ПП
User 228403837
но это я как бэкэндщик говорю)
12:25:59 ПП
User 128597654
мне именно твое мнение интересно 🙂
12:26:19 ПП
User 128597654
а где можно прочитать по событийную модель?
12:26:26 ПП
User 228403837
я всякими там domain events упарываюсь
12:27:03 ПП
User 228403837
ну то есть это не такое событие как обычно, а именно факт того что что-то произошло. Ну мол если у тебя есть ивент что кто-то что-то сделал - значит это уже факт
12:27:53 ПП
User 228403837
ну это удобно когда ты еще всякими там ddd загоняешься и прочими модными словами
12:28:37 ПП
User 128597654
тогда получается лучше создать таблицу с уведомлениями (с ссылками на данные факта) и информацией о просмотре уведомления
12:28:51 ПП
User 128597654
а пуш информацию тут же хранить или отдельно?
12:31:38 ПП
User 228403837
зависит от того важно ли тебе различать их или нет
12:31:46 ПП
User 228403837
обычно это не важно, но допускаю что иногда надо отдельно
12:32:14 ПП
User 228403837
ну мол обычно push это лишь способ доставки. У меня например пользователь может выбрать 3 типа доставки (или все три) но нотификация то одна и та же
12:32:40 ПП
User 128597654
мне важно учитывать количество пуш уведомлений суммарно в день/неделю, время отправки
12:33:07 ПП
User 228403837
ну ты можешь отдельно лог вести как и чего и когда ты отправлял, или просто доп поле в табличке типа как оно было отправлено
12:33:51 ПП
User 128597654
и это по мимо этих уведомлений, потому что есть куча других триггеров для пушей
12:33:53 ПП
User 228403837
ну мол... тут уже как удобно. Я просто предпочитаю всю логику нотификаций максимально отделять от логики которая эти нотификации порождает (типа юзер что-то сделал - создался доменный ивент, листенер подписался на этот ивент и отправляет нотификашки. А что там и как внутри - зависит от задачи)
12:34:19 ПП
User 228403837
User 128597654
и это по мимо этих уведомлений, потому что есть куча других триггеров для пушей
ну если не только нотификашки вызывают пуши - то тебе надо на уровне инфраструктуры метрики трекать
12:34:26 ПП
User 228403837
я бы во всяком случае так делал, тупо логгером каким
12:34:36 ПП
User 228403837
или промитей бы настроил
12:34:45 ПП
User 128597654
я думал про elk для логирования
12:34:45 ПП
User 228403837
ну короч тут все очень зависит от того что ты юзаешь, что тебе надо и т.д
12:35:05 ПП
User 228403837
User 128597654
я думал про elk для логирования
я для таких целей использую prometheus
12:35:20 ПП
User 228403837
ELK удобно что бы посмотреть что делалось
12:35:28 ПП
User 228403837
а тебе по сути мониторинг нужен и метрики собирать
12:36:00 ПП
User 128597654
даа, что делалось, а мне нужно немного другое, потому что это влияет на будущую бизнес логику
12:36:19 ПП
User 228403837
User 128597654
даа, что делалось, а мне нужно немного другое, потому что это влияет на будущую бизнес логику
бизнес логика зависит от того сколько раз были отправлены пуши?
12:36:36 ПП
User 228403837
даже интересно что ты такое делаешь)
12:36:54 ПП
User 128597654
да, например, если пуш был за сегодня, то дополнительные пуши (рекомендации для возврата в приложение) я не будут отправлять пользователю
12:39:03 ПП
User 128597654
проект с социальным взаимодействием пользователей
12:39:33 ПП
User 228403837
ну тогда учитывать историю нотификашек
12:39:54 ПП
User 228403837
а что значит "есть куча других триггеров для пушей"...
12:39:59 ПП
User 228403837
и должны ли они учитываться?
12:40:06 ПП
User 228403837
или может быть проще хранить тупо все?)
12:41:44 ПП
User 128597654
Пуши:
- чат сообщения
- сами социальные взаимодействия (не все)
- рекомендации что подойдет для пользователя
12:42:47 ПП
User 128597654
Лента нотификаций:
- только социальные взаимодействия пока
12:43:50 ПП
User 228403837
чат сообщения влияют на логику?
12:44:18 ПП
User 228403837
или все влияет? если влияет все - надо все хранить, или как минимум хранить какую-то отметку когда отправлялись пуши в последний раз, или агрегировать статистику за день
12:44:26 ПП
User 228403837
тут сильно зависит от вашей специфики
12:44:39 ПП
User 228403837
я тут подсказать ничего не могу, я просто загоняюсь по уменьшению связанности)
12:45:01 ПП
User 128597654
чат да, еще пуши завязаны на просмотрах, смотрел ли пользователь это или другое
12:45:40 ПП
User 228403837
тут тоже есть нюансы. Например что считается что нотификация просмотрена - возможно хватит тупо курсор хранить, а иногда надо каждую в отдельности чекать
12:45:53 ПП
User 228403837
а иногда приходится смешивать
12:47:22 ПП
User 128597654
это тоже вопрос для обдумывания, я вижу это как отдельно каждую ситуацию, поскольку курсор может перемешаться с доставленными пуш уведомлениями
12:49:30 ПП
User 128597654
Сергей, похоже надо отдельно хранить
- Нотификации (записываются от разных триггеров)
- Пуш уведомлений (тоже от разных триггеров)
12:49:59 ПП
User 228403837
возможно, так как у тебя пуш нотификация самодостаточная сущность
12:50:39 ПП
User 128597654
надеюсь она будет умной 🙂
12:50:53 ПП
User 128597654
спасибо
08:18:51 ПП
User 371133717
https://medium.com/@FdMstri/testing-a-graphql-server-13512408c2fb

Что думаете ребят?
medium.com/@FdMstri/testing-a-graphql-server-13512408c2fb
This is the ✌️ second article from the series “Build a Pokédex with GraphQL, React.js, Semaphore CI, Heroku and Docker”.
08:19:02 ПП
User 371133717
Что думаете ребят?
10:00:16 ПП
User 228403837
ничего не думаю, я сейчас просто заставляю при отдаче ответа API проверять ответы на соответствие схемы и чуть что писать в лог
10:00:43 ПП
User 228403837
дальше e2e тесты + чуть-чуть интеграционных сделают свое дело. Так же подумываю на тему статического анализа
10:00:58 ПП
User 228403837
но тестить филды вот так как предлагают в статье - ну можно но удобно только для примитивных вещей
10:01:10 ПП
User 228403837
это как тестить геттеры
10:01:21 ПП
User 228403837
зачем если ты можешь типы проверить