eRKa

Если идете в веб, то без базовых знаний фронта полноценно решать задачи даже бэка не получится. На каком то уровне знать что там происходит и как работает - нужно. Может Вам и не придется решать конкретно фронтедные задачи, но читать код и что-то с чем-то согласовывать - придется.

А так , да. Чистый бэкендщик сейчас мало кому нужен. Не ради экономии денег, ради экономии времени, чтобы не буцать и не блокировать задачи. Дали задачу реализовать часть отображения данных, делаешь бэк для получения данных и сам же делаешь отображение. Не нужно тратиться на согласовывание между двумя и фронту ждать, когда бэк что сделает, а потом, если что-то не так, опять возвращать на бэк и т.д.

Если время на фичи выделите Вы, с большой долей вероятности, это время будет провалено. Задачи должны оценивать те, кто эти задачи будет выполнять. Судя по вопросу, Вы не в курсе возможностей своих отделов, нюансов реализации и т.д., значит не сможете адекватно оценить их затраты по времени. Когда поработаете с ними пол годика-год, тогда, возможно, Вы и станете понимать на что они способны и какие типовые задачи за сколько сделают. Ключевое слово "ТИПОВЫЕ", т.к. на нетиповые неопределенность временных затрат резко возрастает.

Зачем Вам gulp к webpack-у? С большой долей вероятности, проблема из-за него, причина ошибки в трейсе написана, это циклическая зависимость

20 error code ELIFECYCLE
21 error errno 1
22 error kokos-uwidget@0.1.0 build: `node node_modules/webpack/bin/webpack.js && node node_modules/gulp/bin/gulp.js`
22 error Exit status 1
23 error Failed at the kokos-uwidget@0.1.0 build script.

Если памяти не хватает, то без разницы сколько потоков Вы используете. Многопоточность нужна либо для асинхронности, либо для параллельности. Добавление потоков памяти не сэкономит, даже наоборот, увеличит ее расход и даже иногда скорости не добавляет.

Если у Вас есть некий список, с которым работает много потоков, то рассмотрите возможность использования потокобезопасных коллекций. List не потокобезопасен.

Если у Вас большой объем данных, который не влазит в память, то только подгружать данные частями, если хотите добавить параллельную обработку этих данных в разных потоках, то ,возможно, Вам подойдет Parallel.ForEach.

И да, нет необходимости добавлять 100 потоков, как уже сказали, такое кол-во в кол-во ядер не влезет и производительности это не добавит, а даже наоборот, т.к. одно ядро будет делить время на часть выделенных потоков и будет переключать контекст между ними. Не факт, конечно, что даже два потока будут разделены по ядрам, за это ОС отвечает, но 100 потоков, это кажется перебором. Можно, конечно поэкспериментировать с кол-вом и посмотреть на производительность при этом.

Не понимаю, зачем для тестирования апи разворачивать фронт. Бэк самостоятельно нормально может проверить работоспособность своего апи. Для этого как минимум есть браузер, как максимум есть postman или swagger и куча их альтернатив. Фронт говорит какие ему данные нужны, бэк говорит как будет называться метод и какие параметры с фронта для этого должны передаваться. А дальше как работает фронт, это проблема фронтедщиков.

Невозможно разобрать программу не разбираясь в технологиях на которой она сделана и в платформах, для которых она создана. А для того, чтобы сломать, нужно научиться еще и писать на этой технологии. Так что без матчасти (.net, il, ассемблер, ос, сети и т.д.) никуда. Дерзайте в их изучении.

Формат такой строки называется JSON. Есть много способов, как преобразовать dictionary к json. Например,

using System;
using System.Collections.Generic;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
using Newtonsoft.Json.Converters;
using Newtonsoft.Json.Serialization;

Dictionary<string, string> headers = new Dictionary<string, string>();

headers.Add("user-agent","mozilla");
headers.Add("pragma","no-cache");
headers.Add("referer","google.com");

var jsonString = JsonConvert.SerializeObject(headers);
Console.WriteLine(jsonString);  // {"user-agent":"mozilla","pragma":"no-cache","referer":"google.com"}

Читаете только в контролере, получив через инъекцию IConfiguration . Дальше передаете нужные параметры настроек в объект, либо при его создании через конструктор, либо передаете параметры через методы этого объекта. Передаете только те параметры, которые непосредственно нужны этому методу.
Конфиг может разрастаться, и передавать его весь в объект ради пары параметров не стоит, объект в этом случае может получить доступ к тем полям, которые его не касаются вообще.

Не все проекты делаются на js фреймворках, во многих asp проектах он еще используется, не как основа, скорее как дополнение к js на странице. Если собираетесь работать в стеке asp, то мимо razor всеравно не пройдете.

Наверное потому, что clearTimeout(xhrTimeout) срабатывает раньше, чем проинициализируется xhrTimeout и на клиенте падает с ошибкой.
Александр Черемхин Вам правильно написал, сначала инициализация xhrTimeout, а потом только вызов.

1..* это описание связи один ко многим и ее обратная зависимость 0..1, многие к одному. Тут

Человеческие названия обычно уже делают на клиенте, по типу
<label>Тип:{{entity.type}}</label>
В базе редко хранят, что-то, что не меняется. Имена Ваших ключей навряд ли изменятся, а данные будут меняться постоянно.

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