Комментарии 3
Почему бы не сделать так, что бы "язык пользователя" передавался клиентом в запросе (например через HTTP заголовок Accept-Language)? Его можно использовать для формирования ключа к кешу. Тогда не пришлось бы заморачиваться с очисткой кеша по сообщению из Кафки и не было бы задержки.
Это ведь один из архитектурных принципов в диссертации Филдинга для создания масштабируемых распределённых приложений. Данные, необходимые для выполнения запроса, должны приходить от клиента. Как только вы пытаетесь брать эти данные ещё от куда-то — это становится бутылочным горлышком и мешает горизонтально масштабировать приложение.
Спасибо, хорошая идея, это упростило бы чистку кеша и сделало бы его более целостным, да и в целом логично, возможно мы к этому и прийдем. Пока мы такой подход к критичным данным только применяем.
Тут из недостатков то что язык пользователя надо знать и передавать со стороны клиента, когда собственно данных о пользователе (и его языка) еще не загружено. Надо соответсвенно либо кешировать язык в браузере в куках или localStorage, либо полагаться на настройки браузера, либо делать несколько запросов. Соответсвенно надо менять логику webapp и мобильных клиентов.
И вторая потенциальная сложность с усложнением бекенда — мы иногда из админки чистим весь кеш компании (и всех ее пользователей). Чем больше комбинаций разных данных в ключе (companyID, userID, customFieldType… language), тем больше надо проходится по мемкешу, потому что он у нас не умеет удалять все по wildcard. Тут мы получается должны умножить количество ключей на количество языков которые мы поддерживаем.
Впрочем, если мы все-равно будем сохранять язык на бекенде то можно чистить точечно…
Но тогда может получиться что и у клиента язык сохранен на фронтенде… и на бекенде он есть. Кому доверять?
Тут из недостатков то что язык пользователя надо знать и передавать со стороны клиента, когда собственно данных о пользователе (и его языка) еще не загружено. Надо соответсвенно либо кешировать язык в браузере в куках или localStorage, либо полагаться на настройки браузера, либо делать несколько запросов. Соответсвенно надо менять логику webapp и мобильных клиентов.
И вторая потенциальная сложность с усложнением бекенда — мы иногда из админки чистим весь кеш компании (и всех ее пользователей). Чем больше комбинаций разных данных в ключе (companyID, userID, customFieldType… language), тем больше надо проходится по мемкешу, потому что он у нас не умеет удалять все по wildcard. Тут мы получается должны умножить количество ключей на количество языков которые мы поддерживаем.
Впрочем, если мы все-равно будем сохранять язык на бекенде то можно чистить точечно…
Но тогда может получиться что и у клиента язык сохранен на фронтенде… и на бекенде он есть. Кому доверять?
- Если клиент где-то уже хранит у себя "сессию" (хотя бы авторизационный токен), то точно там же можно хранить и выбранный юзером язык. А пока юзер не авторизовался, то очевидно клиент даже из бекенда не получит эти данные. В качестве дефолта, можно временно использовать настройки браузера, пока пользователь явно не поменяет его.
- Если ваш кеш работает на уровне HTTP, то можно взять готовые решения (например Varnish) которые умеют в wildcard. Или заменить memcache на Redis, он умеет в wildcard.
- Лучше и проще доверять клиенту. А настройку в бекенде использовать для отправки пользователю всяких рассылок и уведомлений, когда нет информации о языке клиента, который будет просматривать эти сообщения. Это позволит пользователям настраивать на разных клиентах разные языки независимо от настроек бекенда. Так же можно использовать настройку из бекенда в качестве дефолта, если вам вдруг почему то не нравится использовать настройки браузера в качестве таковых. Получать эту настройку можно в момент авториазции юзера. А до тех пор использовать настройку браузера или куки/localStorage, в которых можно сохранять язык с последней "сессии".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Путь к Федеративному GraphQL