А сервис может убивать эту инфу в загружаемом (если оно сохраняется?). Хотя вот локально я бы, как раз, хотел полные сканы хранить. Так и делаю в общем-то, но без распознавания и систематизации какой-либо кроме директорий в файловой системе NAS.
Ну это просто подача такая. Есть ещё, например, Бугаенко. Он в том же стиле пишет и тоже нельзя верить на слово (как впрочем и тем, кто пишет в менее уверенном стиле).
Про ORM не согласен. Да, запросы вида SELECT id; SELECT * WHERE id IN (1,2,3) — они не самые оптимальные, но, как правило, далеко не критично влияют на производительность. При этом такое поведение ORM даёт то, что можно выбирать ID из одной базы, а данные из другой:
Иногда это сильно упрощает жизнь при разрезании монолита на несколько частей по-честному (то есть без общей базы). У меня такое было.
Это позволяет выбирать ID из одной базы, а данные из другой. Например, ID из ElasticSearch, а данные из основной базы. У меня сейчас так работает на нескольких проектах.
Мы его сравниваем с хранением payload в Redis и походом в него. То есть гоняем только ID-шник сессии, например, в httpOnly cookie и всё. Например, так умеют стандартные сессии в том же PHP.
Ответ: конечно можно, но количество таких токенов будет существенно больше. Это увеличит объем потребляемой памяти, и замедлит запросы к БД. больше данных => медленнее поиск в БД.
В Redis поиск по ключу — это алгоритм сложности O(1). То есть не зависит от количества ключей и не замедлит запросы к БД.
Также Redis хранит данные довольно компактно и лимит по ключам на одном инстансе даже со скромным количеством памяти — десятки миллионов. Учитывая expiration, упереться в это вряд-ли получится для большинства сервисов.
Отсюда ещё раз вопрос: а так ли нужен JWT если инвалидировать токены нужно?
Для Synology мало смысла сейчас писать плагины-приложения. Там Docker нормально работает.
А сервис может убивать эту инфу в загружаемом (если оно сохраняется?). Хотя вот локально я бы, как раз, хотел полные сканы хранить. Так и делаю в общем-то, но без распознавания и систематизации какой-либо кроме директорий в файловой системе NAS.
LLM-ку сделать настраиваемой: OpenAI API и ollama API будет более чем достаточно.
Очень даже. А планируется self-hosted опция? Доверять свои медицинские данные сервису не очень хочется.
Не похоже.
https://www.pckeyboard.com/mm5/merchant.mvc?Screen=PROD&Product_Code=UB40B5A
Например, чтобы не раздувать стек если основная система на PHP.
Ну, по-первых, есть fibers. Во-вторых, есть ReactPHP, Amphp, Swoole.
Ну это просто подача такая. Есть ещё, например, Бугаенко. Он в том же стиле пишет и тоже нельзя верить на слово (как впрочем и тем, кто пишет в менее уверенном стиле).
Книги неплохие. Они заставляют подумать. Проблема не в книгах, а в фанатиках, которые бездумно воспринимают информацию и не проверяя верят ей.
@AmneziaAdept а можете списки IP/доменов/подсетей выложить у себя на GitHub чтобы проще было split tunnel настроить у себе через ваш клиент?
Так уже хуже, конечно.
Про ORM не согласен. Да, запросы вида
SELECT id; SELECT * WHERE id IN (1,2,3)— они не самые оптимальные, но, как правило, далеко не критично влияют на производительность. При этом такое поведение ORM даёт то, что можно выбирать ID из одной базы, а данные из другой:Иногда это сильно упрощает жизнь при разрезании монолита на несколько частей по-честному (то есть без общей базы). У меня такое было.
Это позволяет выбирать ID из одной базы, а данные из другой. Например, ID из ElasticSearch, а данные из основной базы. У меня сейчас так работает на нескольких проектах.
Да, в качестве эксперимента не подходит. Верно.
В моём случае профгигиена + плазмолифтинг + уход дали хороший результат.
В том и дело что попробовал. Сработало.
Что насчёт плазмолифтинга?
Мы его сравниваем с хранением payload в Redis и походом в него. То есть гоняем только ID-шник сессии, например, в httpOnly cookie и всё. Например, так умеют стандартные сессии в том же PHP.
В Redis поиск по ключу — это алгоритм сложности
O(1). То есть не зависит от количества ключей и не замедлит запросы к БД.Также Redis хранит данные довольно компактно и лимит по ключам на одном инстансе даже со скромным количеством памяти — десятки миллионов. Учитывая expiration, упереться в это вряд-ли получится для большинства сервисов.
Отсюда ещё раз вопрос: а так ли нужен JWT если инвалидировать токены нужно?
businessDaysBetween(a, b)?