MishaXXL

useSelector внутри себя использует хук useSyncExternalStore (точнее, хук, аналогичный ему)

вкратце суть работы: из редуксового контекста (того самого, который использован внутри Provider) достается редуксовый же стор. Этот стор постоянный, но в нем есть состояние - объект, ссылка на который меняется при каждом изменении, ибо иммутабельность. Подписываемся на изменение этой ссылки (т.е. по факту на изменение любой части состояния), у стора есть метод subscribe для этого. При срабатывании эвента забираем наши данные селектором, и если результат селектора отличается от предыдущего раза, значит изменились именно наши данные и надо пнуть компонент, чтобы обновился, это уже useSyncExternalStore знает как сделать.

Дурным тоном считается создавать работу для сборщика мусора, как бы быстр он ни был, его работа потребляет ресурсы, которые не безграничны и стоят денег.

str создает еще одну запись и ссылается на последнее значение

Зануда мод: не переменная что-то создает, а JVM помещает новую строку в пул, если использовать создание строки литералом, а не конструктором. А потом ссылку на выделенную область памяти помещает в str

В какой момент сборщик мусора решает очистить наш String Pool от лишних значений и почему он это делает не так быстро, что конкатенации строки считается дурным тоном?

До Java 6 String Pool жили в отдельной области памяти, которую GC не чистят (т.е. единожды объявленная строка жила до завершения программы, даже без ссылок). Начиная с 7-ки пулл перенесли в основную кучу, где его может почистить GC. Не не забываем, что и сам гарбадж коллектор не сферический конь, а имеет с десяток реализаций, в каждой из которых есть свои настройки - не копал эту тему, но подозреваю, что можно настроить "неприкосновенность" String Pool даже в общей куче (но зачем?)

Вторая часть вопроса бессмысленна. Забудь про строки. Пусть у тебя есть некий класс А. Твой вопрос эквивалентен следующему: Почему считается дурным тоном создавать множественные объекты класса А и каждый из них присваивать в одну и ту же переменную? Это медленно и расточительно к ресурсам!

Upd. Тут подробнее: https://topjava.ru/blog/rukovodstvo-po-string-pool...

Вам надо вместо абстрактного класс использовать интерфейс, но getInstance() вам в этом интерфейсе не нужен.
В идеале, методы жизненого цикла бина (экземпляра объекта) следует вынести в отдельный класс (класс не должен знать как себя инстанцировать - это не его ответственность).

Во-первых - статические метод нельзя перезаписать. Он принадлежит классу и выгружается в память до запуска программы.
Во-вторых - зачем для Singleton создавать какой-то абстрактный родитель? Советую почитать о вариантах создания "правильного" синглтон здесь https://habr.com/ru/articles/129494/
В твоем случае я бы убрал getInstance из абстрактного класса. То есть - абстрактный класс задает контракт, а конкретная имплиментация Sql - является синглтоном. А какой-нибудь NoSql будет не синглтоном.
Но вообще лучше пересмотреть такую структуру

Если завтра вы захотите сделать получение пользователей по какому-либо принципу (роль, фамилия, дата регистрации), то метод readAll разрастётся ещё сильнее и вы будете передавать в него очень много параметров. Это неправильно.

Так же у вас ошибка - в методе readAll не может быть и получения всех пользователей, и получения их количества (count). Подсчёт строк - это отдельный метод, который отдельно должен дёргаться в роуте. Метод readAll только получает пользователей.

Относительно вашей проблемы - проще всего использовать готовую ORM, а не пытаться самому её написать. Но по каким-то причинам ORM не хочется, достаточно сделать вместо нескольких параметров один объект - запрос и передавать его.

Важно, что передав объект, вы должны его правильно преобразовать в SELECT. Этим может заниматься сам объект, например. А можно написать ещё один, который будет преобразовывать объекты запросов в SQL-строку, которую вы уже будете использовать в readAll.

Как перезапустить только один из сервисов с обновлением volumes?

Добавляешь новый вольюм в docker-compose файл и запускаешь docker compose up -d service.
сервис обновится и вольюм добавится

И можно в контейнерах указать не отдельные файлы, а папку всего nginx сразу?

Можно

Потому что обычно в sites-enabled лежат не файлы, а символические ссылки на файлы в папке sited-available.

$ ls -l /etc/nginx/sites-enabled/default 
lrwxrwxrwx 1 root root 34 ott 24 10:54 /etc/nginx/sites-enabled/default -> /etc/nginx/sites-available/default

Так что нужно добавить и эту папку тоже.

Ну или удалить эту ссылку, всё равно это заглушка и ни в каком реальном проекте она не нужна.

Fetch это промис.
Промис возвращает твою "data" и соответственно типизировав data и то, что возвращает callback, ты типизируешь данные которые он возвращает.

Однако catch здесь тоже нужно учесть, т.к. он возвращает Promise<any>, соответственно тебе нужно использовать примерно такую конструкцию:

const getData = async (url: string): Promise<Res | any> => await fetch(url).then((data: Response): Promise<Res> => data.json()).catch(err => err.message);

Если перейти по ссылке на сайте, то можно увидеть, что для хранения используется LowDB.
Ответ: хранится все в JSON файле в денормализованном виде

На сколько популярно и корректно хранить данные в столбце в виде JSON строки?

А это зависит от того, что с этими данными делать.

Если сохранить/вернуть - да, вполне.
Если найти по фрагменту - 50/50, и зависит в основном инструментов, имеющихся в конкретной СУБД.
Если выполнить более сложную обработку (сумма, в т.ч. с накоплением, среднее, медиана и пр.) - скорее нет.
Если использовать для связывания по фрагменту - почти наверняка нет.

1. В реляционных базах - обычно это признак чего-то нехорошего, хотя сейчас во многих есть нативная поддержка JSON (в постгресе так она вообще очень хорошая)

Это строки в JSON формате или отдельные таблицы?

Можно и так и так, но
2. Если бы я хотел такую структуру получить в ответе, то geo я бы хранил просто в отдельных двух колонках в адресе. Сам адрес - в отдельной таблице. Компанию - тоже в отдельной таблице.
А для выдачи результата - джоинил.
А если это всё относится только к сущности пользователя (тоесть нету такого, что несколько пользователей относятся к одной организации, которую нужно дедуплицировать) - можно всё в одной таблице и хранить, но в разных колонках (и просто при выдаче результата приводить это к объектной модели)
Либо же иметь одну json-колонку, в которой иметь произвольное количество дополнительных/опциональных полей.

В конце 20-го века, когда Эдгар Кодд развивал свою реляционную теорию было очень
модно все данные нормализовывать для хранения их в БД. Это соотвествовало экономии
ресурсов (диски мерялись килобайтами и мегабайтами) и нормализация хорошо ложилась на
техно-стек. Все данные должны быть атомарны. И ты - плохой DBA и программист если
кладешь в ячейку что-то более комплексное чем просто атом.

В 2000х развитие веб и XML(XHTML/SGML, XSLT, XPath) дало толчок новым видам
хранения информации в виде markup languages. Появляются технологии семанического веба.
Мечтатели-теоретики создают RDF, OWL. Базы данных пытаются успеть втянуть в себя новые типы.
Oracle начинает поддерживать XML+Schema как тип данных в таблице. Браузер начинает
поддерживаеть трансформацию XML и обогащение его стилями. XML - моден. Его внедряют
везде где можно и где не нужно. Даже в конфигах Apache Http и в сборщике Maven.

Параллельно Дуглас Крокфорд работает над Java Scrip Obj Notation и создает лайтовый язык
для описания объектов и документов. Они - конкурируют с XML но JSON практически побеждает
в вебе, полностью захватывая веб протоколы (Ajax, WebSockets, e.t.c). И интеракцию с сервером.
JSON становится более популярный для REST. Многие БД тоже начинают поддерживать JSON.
Postgres даже делает бинарный JSON и добавляет спец-индексы для быстрого поиска атрибутов.
Узко-специализированные системы такие как Mongo изначально заточены на храннение JSON
информации.

BigData плавно проростает в 2007 (кажется) и где-то в 2014 (или позже) году фреймворк Spark начинает поддерживать DataFrames + Structured Types которые по сути являются зеркалом JSON. Фреймворк
позволяет грузить в бигдату JSON-lines датасеты, автоматически выводя схему.

Это - финал. Я считаю что после такой конвергенции в бигдату JSON получил путевку везде где только можно.
Сегодня вы можете без стыда использовать JSON везде в любых уровнях стека (даже в Redis) если
у вас хватает памяти и вы уже порешали вопросы бизнес-согласованности данных и умеете эти
данные инвалидировать и обновлять.

Если поискать анти-паттерны применения JSON в базах данных - то я-бы предложил такую метрику.
Если вы очень часто обновляете маленькое поле внутри большого JSON документа и это создает
сильные I/O нагрузки то скорее всего вам надо перепроектировать вашу БД как-то по другому
и вынести это поле во вне по отношению к документу

Почему все методы StringBuilderнельзя было поместить в класс String, чтобы не плодить классы строк?

Главный поинт при создании immutable String - безопасность кода. Когда компиллятор точно
знает что value строки не изменится - то он может доказать много кейсов и гарантировать что
разделяемая память не будет сломана. Особенно это важно для мультипоточки. Когда
разные потоки владеют строкой и здесь сам вопрос доказательства вдруг становится очень важным.

Язык С++ например такой защитой не обладает и для него строка как фундаментальный тип
может иногда мутировать. Тоесть если вы старались писать правильно то она конечно не мутирует.
Но в этом есть большая разница между C++ и Java. На уровне платформы гарантировано отсуствие
какого-то класса ошибок.

StringBuilder - это попытка улучшить перформанс для кумулятивных строк. Тоесть например
если вы формируете текстовый файл-отчет в памяти то вы будете постоянно делать конкатенации
строк. Это конкатенации вызовут аллокацию-уничтожение памяти. (в скобочках помним
что строка - не мутабельная поэтому изенить ее можно только создав новую копию с добавлением
чего-то нового. Причем с учетом роста самой строки , драматично будет расти эффект нагрузки на память.

Специально для уменьшения этой проблемы (реаллокации и копирования) был создан StringBuilder.
Это вообще не строка а как-бы мутирующий буфер куда можно добавлять в хвост строки. И в конце
когда все готово - из буфера берется иммутабельная строка и на этом работа билдера закончена.

Immutable строки - это гениальное изобретение. Оно реализовано во многих языках и платформах
и оно практически спасает разработчика бизнес-приложений от трудно уловимых ошибок.

Скорее всего коды SQL ошибок зависят от DBMS. Например я по старой памяти помню что если
в коде вы видите ORA-00001 то вы скорее всего используете Oracle и ваша ошибка
связана с нарушением Primary KEY во время INSERT/UPDATE.

Другие DBMS (Postgres/MySQL) будут иметь другие коды ошибок.

Тут логика такая: при первой попытке получить синглтон он будет инстанцирован.
Конструктор приватный для того, что бы не было возможности инстанцировать синглтон никак иначе, как через метод getInstance.

Но подразумевается, что всё-таки правильная конструкция должна быть
Singleton single = new Singleton();

Таким образом появится возможность получить неограниченное количество экземпляров класса, что противоречит идее синглтона.

Вот неплохая статья по этому поводу: https://habr.com/ru/articles/129494/

1. Java (JDK/JRE) не содержит в себе драйверов доступа к БД вообще. В ней определен только базовый
интерфейс java.sql.* и существует некий стандарт на то как драйверы должны работать. Например когда мы делаем ResultSet::close, или Statement::close, драйвер может ничего и не делать в этот момент. Все зависит от того
как производитель (Oracle, MSSQL) реализовал под капотом работу драйвера. Поэтому как работает внутри драйвер это - тайна.

2. Обычно если в приложении тебе часто и много нужно создавать объектов Connection, то используют пулы коннектов (Hikari Connection pool, DBCP, C3PO). Почитай в этом направлении. Пулы экономят сессионные
объекты на стороне БД и создают новые коннекты быстрее за счет переиспользования сущесвтующих коннектов.
В обычном (прямом режиме) работы с БД процесс установки соединения может занимать несколько секунд.
Это может быть запредельно медленно для некоторых алгоритмов.

3. В сложных ent. приложениях используются фреймворки типа Spring которые декларируют зависимости одник
компонент от других и также обеспечивают ленивую инициализацию и работу синглтона. Всем новичкам
нужно знать что такое синглтон и уметь им пользоваться. И лучше уметь это сначала без фреймворка
чтобы понимать уже как это делает фреймворк.

Подключи к проекту драйвер

https://mvnrepository.com/artifact/org.postgresql/...

Массив — структура данных хранящая набор значений, в простейшем случае фиксированой длины. Массивы не всегда удобно использовать, поэтому ряд языков программирования поддерживают динамические массивы и, Java один из таких языков. ⇨ Данные типа String - это массив char-ов в таких языках как Pascal, C, C++, Java и др.. В Java все строковые литералы помещаются в специальный объект (класс) под который выделяется память, а уже адрес этого объекта помещается в переменную, под которую тоже выделяется память. Java коллекции расширяют возможности работы с массивами и это пожалуй ответ на все ваши вопросы.
https://javarush.com/quests/lectures/questsyntaxpr...

Например, если вы заполните HashSet<String> то сможете проверить наличие определенного String-а в массиве строк, заменив s.equals(sb) на list.contains(sb) Такой код будет работать в оперативной памяти используя hashcode (32 битный идентификатор объекта). Это работает быстро и эффективно, так как числовые значения гораздо легче и быстрей сравнить. Однако, каждая строка будет представлять собой отдельный объект и занимать свою ячейку в памяти.

При конкатенации происходит приблизительно то же самое: Создаётся массив, где каждая строка - это отдельный объект (массив) разного размера. В момент конкатенации создаётся новый объект типа String с размером == сумма двух String и + 2 объекта "склеивания". А если у нас таких операций (итераций) много, то велика вероятность получить outofmemoryerror прежде чем GC (сборщик мусора) успеет собрать все созданные объекты.

В отличие от языков C/C++ в Java нет доступа к памяти. Программист не может удалить "cell memory" хранящую ссылку на объект и в этом нет необходимости. Эту работу выполняет Garbage collectors (GC) а вся работа с памятью происходит только через Java-машину (JVM).

С целью экономии памяти, начиная с версии JDK 5 для работы со String-ами в Java имеется StringBuilder. Таким образом у нас всегда один объект, который пропорционально заполненяет StringBuffer, подобно HashSet<String> но с одной ("резиновой") ячейкой в памяти.
https://docs.oracle.com/javase/8/docs/api/java/lan...

Полагаю дело в стереотипах: под node неблокирующий io, под java - блокирующий и нет зеленых тредов. Но это не так. В можете взять quarkus с его mutiny и базу поддерживающую неблокирующий вывод (постгре или другую) и будет счастье. Правда java хочет больше памяти, т. к. пока нет возможности маппить сложные стуктуры в память, все через кучу объектных ссылок. Но навряд ли это будет проблемой, если речь не про миллион соединений.
Пишите на том, что вы знаете хорошо. Можете на node, можете на go, можете на java, если хотите - на rust и tokio