Вадим

https://pypi.org/project/json-stream/

Ваша задача следующая.
Определить заголовок и хвост вашего JSON
Определить данные которые повторяются
проходясь в цикле добавлять данные в буфер
после склеить голову тело и хвост и записать в файл и сбросить буфер
если цикл не закончен то повторить

Вот пример

{
  "names": [
    { "name": "1" },
    {"name": 2 }
  ]
}

{
  "names": [
    { "name": "1" }
  ]
}

{
  "names": [
    {"name": 2 }
  ]
}

Так уж повелось, что основное (большее) количество разработчиков работают в среде linux или средах разработки и библиотек, изначально разрабатываемых для работы в linux

Т.е. когда ты видишь модули npm, пакетный менеджер python pip, compose от php и прочее прочее, везде изначально разработчики ориентируются на окружение linux.

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

В linux же выглядит так (решили основные проблемы за тебя) заметно чаще (почти всегда) и часто трудности вылезают при ну очень необычных ситуациях (например попытка водрузить компоненту на не поддерживаемые/старые/новые версии ос или аппаратные платформы).

Linux - это отраслевой стандарт. Не linux сервера могут быть только там где тебя поставили в такие условия намеренно (вендорлок) или по скудоумию. Отсюда не изучать его - глупо и не эффективно.

p.s. на десктопах linux-у плохо именно из-за того что производители железа намеренно (им за это заплатили или чтобы не наказали) тормозят развитие (плюс конечно деньги, зачем тратить ресурсы на поддержку в нескольких средах, когда хватит только одной windows)

p.p.s. да у linux тоже куча проблем, поддерживать все его многообразие иногда настоящий ад

добавить в группу appпользователя www-data

в fpmDockerfile:

USER root
RUN addgroup -g 1000 app && addgroup www-data app
RUN adduser -u 1000 -s /bin/sh -D -G app app
USER www-data

Раньше все зависимости лежали в GOPATH, но это было неудобно тем, что не было никакого управления этими зависимостями. Нельзя было зафиксировать их конкретные версии и нельзя было для разных проектов сделать разные зависимости, потому что все было в одной центральной папке.
Потом в го ввели систему модулей:
https://go.dev/blog/using-go-modules
https://habr.com/ru/company/otus/blog/503918/

Теперь в корневой папке каждого проекта есть файл go.mod, который перечисляет зависимости этого проекта и их конкретные версии. Поэтому необходимость в GOPATH отпала, теперь Go при сборке использует модули, указанные в go.mod и не ходит в GOPATH вообще, это намного удобнее.

Добавлю к ответу Василий Банников
- да, SonarCloud на мой взгляд самый удобный
- я недавно познакомился с https://www.jit.io/. Очень интересный сервис - агрегатор open source security tools. Обещают добавлять новые tools. Не только static code scanning и не только код. Мне очень понравилось - https://www.linkedin.com/posts/vkarasik_devsecops-...

тест coverage

Такой отчёт может CI/CD система выдавать, но для этого тестовый фреймворк должен ей эту информацию сообщий.
Это не статический анализ.
В случая голанга для этого используется go tool cover
Если используется гитлаб, то вот инструкция по настройке:
https://docs.gitlab.com/ee/ci/testing/test_coverag...

code smells и code security issues

Это точно умеет Sonarqube даже в бесплатной версии.
Можно ещё в ci добавить какой-нибудь dependabot или его подобие, который будет смотреть за устаревшими библиотеками. + npm audit

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

Если метод состоит из одного выражения/оператора, то можно убрать фигурные скобки и return, и заменить их на стрелку.

почему первые два возвращают System.Object и как это можно исправить?

Потому-что dynamic под капотом - это на самом деле Object и куча рефлексии.
List<dynamic> - это на самом деле List<object> (можешь загнать в sharplab и убедиться в этом)

Исправить это можешь только отказавшись от dynamic (а лучше вообще забыть о его существовании. Крайне сломанная фича, которая путём говнокода позволяет в некоторых случаях сэкономить строчки)

Например, если нельзя трогать ClientViewModelNew и ClientViewModelOld, то можно попробовать так:

public interface IClientViewModel {
  public string EXa { get; set; }
}

public class ClientViewModelNewWrapper: IClientViewModel {
  private readonly ClientViewModelNew _internal;
  public ClientViewModelNewWrapper(ClientViewModelNew obj) => _internal = obj;
  public string EXa { get => _internal.EXa; set => _internal.EXa = value;}
}

public class ClientViewModelOldWrapper: IClientViewModel {
  private readonly ClientViewModelOld _internal;
  public ClientViewModelNewWrapper(ClientViewModelOld obj) => _internal = obj;
  public string EXa { get => _internal.EXa; set => _internal.EXa = value;}
}

Если говорить об общем подходе - JSON в БД должен использоваться только и исключительно в случае, когда вся работа с JSON ограничивается простейшим "записать в БД" - "извлечь из БД". При этом модификация в момент записи/извлечения можно не учитывать.

Если же JSON используется более нагруженно (поиск, сравнение, частичная модификация и пр.), то в большинстве случаев от его использования следует отказываться в пользу нормализованных plain-структур. При правильном индексировании они выиграют у JSON по потреблению ресурсов сервера. Хотя, конечно, в каждом отдельном случае нужно смотреть конкретные условия - тип использования, возможности оптимизации этого процесса в конкретной (версии) СУБД и пр. Да и то, JSON тут реально может конкурировать разве что с EAV.

Использование JSON объектов в столбцах таблицы базы данных PostgreSQL является приемлимой практикой и позволяет хранить сложные структуры данных в едином формате. Это упрощает их обработку и извлечение нужных данных в запросах. Однако, также следует учитывать, что хранение больших объемов данных в формате JSON может замедлить работу базы данных и увеличить нагрузку на сервер. Поэтому рекомендуется проводить оптимизацию запросов и использовать индексы для ускорения работы с JSON данными.