Comments 6
Данные-то где хранятся? Вот эти самые промо-секунды? Неужели отдельное поле в базе или поле в юзере? И так для всех тысяч эндпоинтов — везде по-разному?
Такие временные данные можно хранить, например, в сессии юзера или в мемкеше
Если отбросить в сторону то, что база не очень быстрая, то поинт с базой был в том, что там значение одно на всех пользователей. Получается что вполне себе можно хранить на каждого пользователя свое значение и в бд (раз можно в мемкэше). Второй поинт был о том, что нужно следить за доступами. Для этого фактически вы написали свой API, через который и следите за правами. но с тем же успехом, опять же, можно выдавать права на одну конкретную таблицу в БД конкретным людям.
Я не то чтобы набрасываю, идея клевая, на больших масштабах и если вернуть тезис про тормозную БД — очень даже интересная. Просто я о том, что вводные о том, зачем это было сделано выглядят притянутыми за уши. Звучит так: «У нас были вот такие проблемы со старым подходом. Но мы не стали их решать, а написали новую систему, где учли их заранее».
Я не то чтобы набрасываю, идея клевая, на больших масштабах и если вернуть тезис про тормозную БД — очень даже интересная. Просто я о том, что вводные о том, зачем это было сделано выглядят притянутыми за уши. Звучит так: «У нас были вот такие проблемы со старым подходом. Но мы не стали их решать, а написали новую систему, где учли их заранее».
Решение через базу имеет несколько недостатков:
Помимо этого QAAPI должен уметь работать с базой пользователей, чтобы выдавать или изменять их данные. Выдавать доступ к такой базе мы точно не можем, так как помимо тестовых пользователей там хранятся и реальные
- если для каждого такого значения (или метода) заводить отдельную колонку, то для каждого метода нужно будет делать alter. Это существенно усложнит создание новых методов
- если хранить для каждого пользователя данные в одном поле, например, в json, то появляется необходимость помнить или искать нужные ключи. К тому же, менять такие данные вручную очень неудобно
- нужно не забывать чистить такую базу от данных удаленных пользователей
Помимо этого QAAPI должен уметь работать с базой пользователей, чтобы выдавать или изменять их данные. Выдавать доступ к такой базе мы точно не можем, так как помимо тестовых пользователей там хранятся и реальные
Ничего не мешает хранить данные в формате «пользователь-ключ=>значение» (три колонки). И альтеры делать не надо и индексы работают и чистить легко и работать удобно. В мемкэше, полагаю, вы данные храните примерно так же, только там можно настроить какой-нибудь expire (который в БД можно реализовать тоже).
> Выдавать доступ к такой базе мы точно не можем, так как помимо тестовых пользователей там хранятся и реальные
Ну, в таком случае, да — надо писать свой интерфейс. При этом как реализовано хранилище опций, кажется, не сильно принципиально.
Я еще раз повторю. Решение клевое. Вводные — нет. У какой-нибудь конторы с пятком разрабов и сервисов на тысячу пользователей в час вполне можно было бы обойтись и опциями в базе, все бы работало огонь.
я просто пишу о том, что эти трудности — выдуманные. реальные требования описаны дальше — это решение должно быть простым, потому что у вас много тестировщиков и более сложное решение просто дороже по их оплате, у вас строгие требования к безопасности и т.д. А подается так, как будто вас не устроила БД потому что в ней вообще нельзя это сделать.
> Выдавать доступ к такой базе мы точно не можем, так как помимо тестовых пользователей там хранятся и реальные
Ну, в таком случае, да — надо писать свой интерфейс. При этом как реализовано хранилище опций, кажется, не сильно принципиально.
Я еще раз повторю. Решение клевое. Вводные — нет. У какой-нибудь конторы с пятком разрабов и сервисов на тысячу пользователей в час вполне можно было бы обойтись и опциями в базе, все бы работало огонь.
Можно было бы решить эту проблему, переместив значение в базу, но и в таком случае возникли бы трудности:
я просто пишу о том, что эти трудности — выдуманные. реальные требования описаны дальше — это решение должно быть простым, потому что у вас много тестировщиков и более сложное решение просто дороже по их оплате, у вас строгие требования к безопасности и т.д. А подается так, как будто вас не устроила БД потому что в ней вообще нельзя это сделать.
Так в чём техническое решение? Где храняться данные и как это выглядит в клиентском коде?
Типа if (это тестер && QAAPI->showPromo(userId)) показать_промо() или как?
Типа if (это тестер && QAAPI->showPromo(userId)) показать_промо() или как?
Sign up to leave a comment.
API для QA: тестируем фичи без доступа к коду