Телеграмм чат группы itarchitect страница 4069

Что именно подразумевается под "фильтрация"?

13:55пожаловаться #1

1. Мутации там вообще безбожно написаны, увы. Никаких гарантий, ничего. Я надеюсь ими никто не пользуется (хотя зря надеюсь, если есть плохая вещь - ей обязательно воспользуются). Ну и кто сказал, что фронтенд - единственный источник мутаций?
2. Т.е. сделать bff

13:55пожаловаться #2

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

13:56пожаловаться #3

Например, выбрать книги, у которых жанр "военная история" и автор - англичанин.
Книги и авторы - в разных микросервисах

13:56пожаловаться #4

Ну вот у нас фронт общается в bff по gql.

13:57пожаловаться #5

Нет, все гораздо сложнее. Нет вообще никакого API, так как нет ограничений на использование graphql и любые реакции на проблемы - становятся реактивными, а не проактивными.
И рефакторинг невозможен, так как нет возможности понять, а что реально используется, а что - нет

13:57пожаловаться #6

Эээ, что это значит? Есть своя реализация конкретных запросов для фронта? И каждый graphql запрос матчится на отдельный метод bff?
А зачем тогда graphql?

Aleksandr Bespalov in Архитектура ИТ-решений

13:58пожаловаться #7

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

14:01пожаловаться #8

Так наличие/отсутствие gql не связано с проблемой. Вариантов тут немного:

1. Сделать 2 запроса и помержить локально.
2. Выгрести авторов, по ним найти книги.

Есть ещё вариант, когда внутри у нас тоже gql и сервис книг может сходить за авторами, поискать у себя и отдать результат.

14:04пожаловаться #9

Если там разные бизнес-сценарии, то нужны разные API.
Если это разные клиенты с одной функциональностью - то проще иметь одно API.
Но обычно десктоп, мобилки, публичные API - все про разное, потому и приходится резать на разные API (там разные подходы к авторизации, разные доменные модели и т.п.)

14:05пожаловаться #10

Не очень понял про "каждый graphql запрос матчится на отдельный метод bff". Нет методов bff, есть пачка резолверов в bff, которые достают данные из внутренних сервисов.

14:05пожаловаться #11

Ну вот gql позволяет это унифицировать. Не утверждаю, что это серебряная пуля, но это лучше чем несколько разных api

14:07пожаловаться #12

Там много разных сценариев в зависимости от селективности данных, которые нужно оптимизировать под конкретную задачу.
Так как и алгоритмов джойнов много и методов вытаскивания данных.
А еще часть данных может быть в аналитической БД и для некоторых запросов лучше пойти туда, а потом проверить актуальность (это популярный кейс для сложных выборок).

14:07пожаловаться #13

Тогда где там bff?

14:07пожаловаться #14

Не, не позволяет. Если разные модели, разные авторизации, разные базовые выборки - то будут разные модели на graphql, разные резолверы, разные скрытые оптимизации.
Ничего не изменится, разные бизнес-кейсы приводят к разным сценариям, graphql не спасет никак.

14:09пожаловаться #15

Универсальное api сложно поддерживать и оно будет строиться по максимуму что умеет самая бедная из платформ.

14:10пожаловаться #16

Нет понятия "бедная из платформ", они просто разные.

14:10пожаловаться #17

У десктопа нет нормального кэша, а мобилке актуален объем передаваемых данных и задержки.
И все, разные решения, разные запросы и так далее.
И никакой graphql не спасет, там идеология разная будет.

14:11пожаловаться #18

Вполне себе есть :) Вот надо поддерживать какой-нибудь iot где с cpu/mem беда и не притащить туда какой-нибудь json. Или же grpc(не web) в браузерах.

14:12пожаловаться #19

Что беднее: пять разных узкозаточенных мобильных клиентов, один десктопный клиент (покрывает по 10% от каждого из мобильных и еще 20% своего), бэкофис или публичное API (покрывает где-то 30% от бэкофиса и 40% от десктопа)?
А это нормальный средний продукт