ларке, если не туда написал, больно не бейте)
Я проектирую систему, потребность от бизнеса такая: нужно чтобы был один супер-админский кабинет и много кабинетов клиентов, причем вторые будут лежать вероятнее всего на отдельных серверах. Пока я смотрю в сторону разделения этой системы на 2 разных rest api, каждый из которых будет разрабатываться на ларке.
Первый API - для личного кабинета Супер-Админа, который может создавать клиентов и управлять их основными конфигами.
Второй API - для личного кабинета клиента. Он будет масштабироваться горизонтально, у каждого клиента - свой сервер / бд / сессии / очереди.
Вот думаю везде использовать UUID вместо стандартных Sequence (autoincrements) ID, чтобы данными ворочать нормально можно было + сразу генерить айдишники придётся в некоторых местах.
Как думаете, нормальная вообще идея так проектировать, с чем я могу столкнуться ещё? Стоит ли юзать UUID во всех таблицах? Я склоняюсь к версии 7.
Нормально
https://www.youtube.com/watch?v=Xr_SNd9LIng Прост на всякий случай скину
Краткость - сестра таланта) Ещё думаю заюзать репы и CQRS, чтобы разделить чтение и запись. Ну и скорее всего какой-нибудь query-builder от шпаттена, чтобы запросы с фронта строить удобно было, как минимум фильтры, сортировка и пагинация нужны..
Доктрину уже бери и не страдай. Вместе с симфони
Спасибо, теперь знаю чем сегодня вечером займусь))
А, собстна, всё, что Валентин рассказал полезного, я тебе кратко изложил😀
Но глянуть полезно и интересно, тема холиварная))
Чот я давно не видел таких холиваров
не, там ещё во время вопросов (вроде) была тема, что ID удобнее для юзеров, нежели по uuid искать
Ну эт и так понятно
Осмотрись вокруг, возможно твоя контора сидит на гос бюджете и возводит супер мега важное и нужное приложение для миллионов клиентов. На первый взгляд, именно такое впечатление от требуемой архитектуры
Вероятность, конечно, крошечная, но очень напоминает одну историю... Так что всё может быть))
Обсуждают сегодня