Антон Швец

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

Складывай прям так, зачем лишняя папка components
Папка должна говорить о смысле, типа

layout
  header
    header-buttons
    header-menu
  footer
    footer-annotation

И тому подобное.

Причем тут вообще Angular? action это аттрибут хтмл-тэга form.
action+method видит браузер и отправляет содержимое формы по указанному адресу. У вас был указан только method, поэтому браузер ничего никуда не слал, т.к. не знал адреса.

ng-pristine ng-valid это классы накладываемые Ангуляром при проверке формы. Т.к. форма у вас никак ангуляром не обрабатывается, проверки пустые и всегда пройденны, форма типа валидна. Эти классы ни на что не влияют и ничего тут не значат.

web-сервер от "не веб" отличается только умением работать через протокол Http
Фактически это и есть обычный сервер, только протокол связи стандартизован, так чтобы с ним умел общаться браузер. Но точно так же с ним может общаться любой другой клиент.

То есть выбор стоит так "использовать мне стандартный протокол или нестандартный". И тут сами выбираете.

Сервер передаёт пользователю видео с видеокамер на которых отображается деталь. Пользователь щёлкая по изображению детали запускает процесс её обработки оборудованием. То есть, будет потоковое видео, тяжёлых вычислений не будет.

Тут в веб тоже есть стандарт - WebRTC, но не слишком удобный, смотрите уже с чем клиент умеет работать.

нет такого понятия - родительский сервис.
Сервисы уничтожаются при уничтожении их инжектора. В случае провайдинга в компонент или директиву, это будет инжектор ноды и он уничтожится когда компонент или директива будет демонтирован. В случае провайдинга в рут или модуль - никогда.

А почему бы не сделать так, зачем эти токены строкой?

class ScreenMediaDevicesService extends MediaDevicesService {}
class CameraMediaDevicesService extends MediaDevicesService {}

providers: [ScreenMediaDevicesService, CameraMediaDevicesService ]

export class CharacterDetailsComponent implements OnInit {
  readonly id$ = this.route.paramMap.pipe(map(paramMap => paramMap.get('id'));
  ....

Все

function filterList() {
  return filter(list=> list!= null && list.length > 0)
}

можно использовать в пайпе.
Остальное - подписка и тейкантил - не нужно

В принципе можно скостылить какого-нибудь уродца, но смысла большого не вижу.
Предпочтительней два пути.
1. Отказаться от tippy в пользу основанной на ангуляре либы.
2. Взять готовую обертку, вот angular-tippy нагуглилось. Может еще что есть, надо смотреть.

switchMap не отменяет никаких запросов. Он отписывается от потока.
А уже HttpClient так устроен, что отменяет запрос при отписке. Т.е. вызывает XMLHttpRequest.abort() когда срабатывает TearDown logic.

Если вы используете fetch, а не xhr, то его тоже можно завернуть в обсервабл. Что-то типа такого

function request(url) {
  return new Observable(observer => {
    const controller = new AbortController()
    const signal = controller.signal
    signal.addEventListener("abort", () => observer.complete());

    fetch(url, { signal  })
            .then(res => {
                observer.next(res);
                observer.complete();
              })
           .catch((err) => {
                observer.error(err);
                observer.complete();
            });

      return () => controller.abort();
  });
}

Писал по памяти, возможно это даже работает :)
При создании Observable переданный ему коллбэк возвращает логику, которая будет выполнена при отписке от него, т.е. teardown

source.pipe(
  switchMap( value => myBooleanSubject.pipe(filter(Boolean), mapTo(value)))
)
  .subscribe(value => ...)

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

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

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

Последнее время поглядываю на esbuild сидя на webpack.

Ну так можно с вебпака никуда не слезать, а для начала собирать js с помощью esbuild-loader вместо бабеля и ts.

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

При запуске дев сервера мы запускаем сервер на ноде который умеет слушать сеть по указанному порту и отдавать статические файлы, собранные вебпаком.
Далее в браузере мы отправляемся по ссылке типа "/api" которая пойдет на тот же самый хост и порт, на котором работает страничка. Этот запрос придет туда же, откуда страница взята, т.е. на наш nodejs сервер.
И там включается разбор запросов, который говорит "ага, вот адрес /api у нас должен проксироваться вот сюда" и сервер на ноде делает самостоятельно запрос по указанному в proxy конфиге адресу, передавая туда же все данные из запроса. Получив ответ, он отправит его под видом ответа от ноде-сервера, который попадет в браузер.

Зачем вообще нам прокси? Чтобы браузер считал что он никуда далеко не ходит, и OPTIONS не слал. И для того чтобы лишние пути во фронте не прописывать, изменить адреса бэкендов для разработки можно подсунув другой конфиг.

А теперь какие такие другие url? Если пойти из браузера по другому url в запущенный прокси он не попадет никогда, если не совпадет айпи адрес хоста и порт.

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