k
ну и типа там какие данные кому нужны, может их разделить можно
Size: a a a
2020 December 23
КГ
ну и типа там какие данные кому нужны, может их разделить можно
getClientsCrm, getClienctPc?)
k
getClientsCrm, getClienctPc?)
мне кажется это сильно зависит от того что там за эндпоинты, что они возвращают
КГ
Хотелось бы всё таки одной апи обойтись, но что-то cost выглядит больше чем benefit
k
Вообще Crm - это интеграция наверное какая-то? С интеграцией обычно какие-то преобразования делать надо всё равно. Ну и не хотелось бы чтобы твой фронт надо было менять, когда поменяется интеграция 🤔
КГ
Вообще Crm - это интеграция наверное какая-то? С интеграцией обычно какие-то преобразования делать надо всё равно. Ну и не хотелось бы чтобы твой фронт надо было менять, когда поменяется интеграция 🤔
crm - "кабинет" админов
k
crm - "кабинет" админов
а админы и обычные пользователи должны видеть одни и те же поля? Там нет ограничений каких-то? Типа "вот это поле можно только админам"?
КГ
а админы и обычные пользователи должны видеть одни и те же поля? Там нет ограничений каких-то? Типа "вот это поле можно только админам"?
есть, и это 80% кейсов
k
есть, и это 80% кейсов
я бы наверное отдельно делал тогда 🤔
k
но я не шарю
DT
Есть апи и 2 личных кабинета. Для админа и для клиента.
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
Я много нового и не очень интересного узнал, когда мы открыли свой backend for frontend внешним интеграторам)
DT
Все что внешникам желательно отдельно, чаще всего
SP
Есть апи и 2 личных кабинета. Для админа и для клиента.
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
На сколько нормальная идея делать 2 разных апи эндпоинта?
Столкнулся с тем, что 80% методов по сути разные. Где то просто ответы разные в силу ограничения доступа к полям. Где то функционал относится только к одному из кабинетов.
Ну то есть я всегда считал, что апи вроде как должна быть client agnostic и бекенду должно быть фиолетово пришел к нему запрос от SPA или запрос по крону от партнёра
Rule of thumb - если нужны ифы под клиента - тебе нужны отдельные эндпоинты
КГ
Получает построить универсальную апи на все случаи достаточно редкий случай и зависит от сути проекта?
k
есть, и это 80% кейсов
возможно стоит даже сделать эти 80% кейсов по отдельным таблицам, но тут уже думать надо, объекты дробить
SP
Получает построить универсальную апи на все случаи достаточно редкий случай и зависит от сути проекта?
Посмотри апишку джиры, она достаточно гибкая
DT
Rule of thumb - если нужны ифы под клиента - тебе нужны отдельные эндпоинты
Даже если ифы пока не нужны, это не показатель
SP
Там ты явно наборы полей нужные передаешь и авторизация на этом уровне происходит
SP
Сложно но универсально
SP
Опять же это больше нужно для интеграции нежели для фронта