niceevolutionjoke, простите. Но вот правда, как вы верстаете и пользуетесь разными программами для этого, если просто выполнить поиск по всему проекту - это неразрешимая задача? Например, найти тег style…, изменить что-то в этом месте и проверить результат?
первое, что приходит в голову - подключить поисковик типа Sphinx или Elastic, и когда пользователь меняет набор колонок, обновлять конфиг поисковика и делать реиндекс. А искать уже через поисковик.
добавлять, удалять элементы в сам код, создавая тэги
тут два варианта - редактируем файл в IDE - это то, что автор и так умеет очевидно. Второй - на лету. Очевидно, что вопрос не про генерацию на стороне backend. Ну мне так кажется.
Уже неважно, вас уже давно отметили.
Вы сами то поняли, что написали? Умничать каждый может. И русские слова никто не отменял.
Если по существу, то продюсеры и консьюмеры появляются как раз в разрезе очередей, т.е. придумали очереди, взяли тот же реббит, создали того, кто ставит задания (продюсер) и того, кто их получает из очереди (консьюмер). А наоборот - это как?)) кто будет между ними? Если они напрямую сами между собой работают, так они тогда и называются иначе, просто компоненты системы.
N, мне лень писать повторно, но вы прочитайте свой вопрос и потом мой ответ. Вам надо запретить кеш, но при этом протухание по времени вам не катит. Вам надо заставить людей каждый раз запрашивать айдишки, но опять-таки запрет юзать их после протухания - не катит. Ну сделайте еще проще - генерите айдишки авторов для теущего юзера апи, пишите их в базу. При запросе книг этого автора по уникальному айди - ставьте ему отметку «протух». Тогда пусть ваши юзеры пьют чай неделями, айдишка их будет ждать.
А про jwt - это тут причем? Я предложил вариант подменять реальные айдишки - виртуальными, чтобы иметь возможность применить к ним протухание.
