Вот это "иногда" и делает эти понятия разными. Четкое определение, хоть и шуточное, против 100 вариаций определения :)
Можно из контекста догадаться, конечно, что имеет ввиду автор строк, но всё таки эти понятия разные

Ну просто нативный в первом контексте включает в себя нативный во втором, так что можно думать что ванильный и нативный одинаковые понятия и точно не ошибиться)

Нужно настроить логирование node js сервера так, что бы клиент имел доступ к логам доступа к ендпоитам (время ответа, ссылка, метод, информация из токена авторизации)

Сейчас все логирует winston и крон собирает это раз в день в архив и выкидывает на облако. Нормально ли засовывать вместо этого логи в монгу (которая уже используется приложением) в capped collection и рисовать интерфейс пользователю используя данные оттуда? Или у этого есть какие то неочевидные минусы? Как вы логируете свои (или не свои) приложения?

Sentry

Но когда у меня на пет проекте была похожая нужда я просто сделал отдельный сервис для логгирования со своей базой и тянул данные оттуда

Не совсем пет проект

как иероглифы вылечить в outlook 7
чарсет писал )
верстка писем ето -

Я понимаю я к тому что я бы сделал как отдельныц сервис и мой основноц сервис ходил бы на него за логами

Поиграйся с кодировками, была такая же проблема именно с аутлуком, по какой то причине если ему письмо приходит в utf-8 то он в целом понимает что это utf-8, но делать с этим ничего не хочет и отображает вот так... Какая то из кодировок тогда помогла, но конкретно какая не вспомню, простите...

Спасибо, звучит резонно, сейчас оно логирует на том сервисе откуда эти логи генерируются

сперва надо вам понять — какая нагрузка ложится на плечи логгера. Потом изучить инструменты на возможности и ваши ресурсы. Например, эластик хорош, но жрёт очень много оперативы. С текущим вашим логгером нет моментального отклика — откладывается на сутки. Ну и всё в этом духе.

А так elastic, mongo, clickhouse, mysql, .txt. Да что угодно, что может решить вашу задачу  :)
За время моей работы логи складывались во всё :)

Точного ответа, вряд ли вы тут услышите. Все они будут субъективны, т.к. у каждого своя задача, не похожая на другие.

Есть какие то критические минусы использовать IndexedDB мне нужно на electron приложение выбор между IndexedDB и sqlite в основном надо много читать с базы

Возможно, я что-то путаю, но IndexedDB это клиентская технология, а sqlite - серверная

у меня приложение electron с vue мне без разницы

sqlite под электроном можно юзать потому что электрон это нода и хромиум одновременно, в свою очередь sqlite хранится в файле а нода умеет в FS IO

собственно вопрос то есть у ка вото практики с IndexedDB может есть какие то проблемы были

Мне и не нужен точный)) самое главное иметь в голове какие то варианты того что можно использовать и из чего выбирать, теперь какие то появились идеи. Спасибо)

Ясно, спасибо, буду знать

Ну все укладывается в ресурсы если у вас докер можно через прицеп сделать контейнер и писать в условную монгу (2), писать логи в действующую базу выглядит плохо в виде перегрузки ее плюс не знаю как сейчас а раньше монго очень любила ресурсы

Ну говорят capped collection помогает в экономии ресурсов, но не пробовал, только слышал, ресурсов немного но расширяемся по нужде, только вот пока понять то что нужно расширяться можно только со слов пользователей т.к внятную статистику получить сложно

Ну буду изучать варианты

ну если докер есть открыть еще один контейнер и в него писать логи отдельно выглядит логичнее всего ты не перегружаешь прод как минимум все зависит от нагрузки rps