ключевые слова для гугла: nginx cookies based auth или nginx auth basic (устаревший, не очень удобный на клиентской стороне но вполне работающий способ)
p.s. есть вполне рабочий способ, не требующий заметных правок nginx и при этом оставляющий статику статикой - это создание симлинков на рабочий каталог файлов сайта, имя симлинка = уникальный идентификатор доступа, выдаваемый после авторизации (собственно на сервере авотризованному пользователю создается этот симлинк, а значит по ссылке с ним пользователь получит данные иначе 404, удаление симлинка - отзыв авторизации), недостаток - не работает кеширование файлов на стороне клиента
Muvka, почему спрашиваешь то? идешь и пробуешь
сам подумай, как приложение определяет что поддержка закончилась, если exe обычно предполагают еще и оффлайн работу?
upd. осторожно, на компьютере должна быть установлена старая версия флеш плеера, а не та что приезжает когда поддержка заканчивается
нет никакой разницы, я описал общее положение при использовании кеша, где он и какого уровня - вопрос алгоритма инвалидации, выбора, сохранять ли данные в кеше или пропустить из мимо.
бред какой, в какие шины данных ты хочешь залезть?
Как я сказал, если тебе нужна цифровая логика, то бери lpt, он самый простой, есть в трети материнок (бывает просто разъемом на материнке но не сзади), а так, все делают общение с компьютером на основе usb, и используют драйвер для общения программы с устройством.
Нужен специальный тестовый сервер и окружение (например локальный dns, подменяющий адрес рабочего сервера или отдельные конфиги самого приложения, направляющие его на тестовый сервер) который должен уметь устанавливать свое состояние по команде юнит тестов.
Наполнение тестовой базы данных, отдельный не простой разговор. Синтетические данные хороши, быстры (их можно сделать мало), но могут не учесть всей специфики пользовательской задачи и тесты проходящие на ней могут не пройти на боевой базе. Но бывает что доступ к самим продакшен данным тестерам давать нельзя по юридическим причинам (приватные данные), и вот тогда придется поизвращаться (замазывание/подмена всего что критично).
В простом варианте - скрипты поднимают в докере сервер и базу данных из указанного бакапа а по окончании тестов этот сервер удаляют. Юнит тесты же должны как минимум быть с пометкой, какая версия базы данных им нужна. Само собой, существуют ситуации, часто, когда тесты требуют последовательно взаимо связаные состояния сервера (т.е. например один тест создает объект, второй его редактирует, третий удаляет, логично что они должны выполняться последовательно либо каждый раз должны откатывать на заранее подготовленную базу данных, что медленнее но надежнее).
Состояние сервера можно хранить снапшотами виртуальной машины (их поддерживают практически все известные), это значительно быстрее но очень требовательно к месту на диске.
p.s. я не участвовал в крупном проекте где требовалось бы так тестировать, а там где требовалось, стратегия запуска тестов требовала только одно стартовое состояние базы данных сервера, а затем куча тестов выполнялось последовательно в непротиворечивом порядке, но если тестов много а нужно заниматься отладкой какого то конкретного, то вышеописанный вариант со снапшотами очень и очень поможет
нажми два раза левой кнопкой мыши на неизвестном тебе слове или выдели как умеешь, затем на выделении правую кнопку мыши, в меню браузера выбери search google for или какой у тебя там поисковик
благодаря гуглу, твой запрос будет понят максимально верно, и будет выдан в первых же результатах ссылка на страницах википедии, где огромное количество людей создали максимально объемный и подробный справочник, аналогов которому в мире нет
в общем случае, без относительно языков фреймворков и т.п. есть два кардинально разных подхода:
* стратегия тонкий клиент, каждый раз, когда тебе нужны данные, делай запрос в базу данных/сервер
* стратегия толстый клиент, клиент хранит все что возможно у себя (вплоть до дублирования функционала сервера), кешируя и отслеживая инвалидацию данных и прочее, красивый вырожденный пример - имея полное состояние базы на каждом клиенте, серверу достаточно пересылать любые события, меняющие эти состояния от клиентов напрямую клиентам (в т.ч. минуя сам сервер, используя p2p), а клиенты синхронно обновляют свое состояние, синхронизируя его друг с другом, используя минимум сетевого взаимодействия (примерно этим подходом пользуются онлайн игры, само собой клиенты хранят только нужный им на текущий момент слепок данных)
По твоим вопросам, да так и делай, это ведь не проблема. redis очень быстрая nosql база данных.
Еще момент, если у тебя websocket сервер, значит веб приложение скорее всего реализовано не http rest принципам а в виде не выгружаемого приложения, а значит многие данные можно не запрашивать постоянно из базы, а хранить в оперативной памяти в глобальных массивах
Между этими двумя подходами нет четкой границы, к примеру можно реализовать тонкий клиент с кешированием данных, для которых контроль инвалидации не критичен или не сильно требует ресурсы или ошибки ожидаемы, весь веб на этом построен.
Абра Кадабра, эээ, если платформа позволяет - то можно закинуть, но не получится так сэкономить на газе, ведь газ это не абстракция, а конкретные затраты (считай количество операций) необходимые для исполнения транзакций, объединив несколько в одну, затраты не изменятся.
да сам с собою, вот только продавать не получится, это ведь как с обычными токенами на эфире, выпустить может любой, а вот ликвидно торговать нужна площадка, где эта ликвидность имеется
в браузере авторизация прописана? твой доступ в гугл аккаунт не угнали (синхронизация вкладок)?
или еще, плагины в браузере какие? туда часто столько треша устанавливает народ, что потом удивляешься почему массово не угоняют пайпал к примеру или тупо банковские карты, используемые в онлайнритейле