FairyTaleComposer

Специально для таких вопросов храню эти две картинки-схемы:

API API рознь.

Если один контроллер и 3 экшена, в которые засунута вся логика - то никому не интересно, даже с навыками фронта.

А вот если API сделано:

- с использованием ООП и паттернов
- многоуровневой архитектурой
- SQL запросами, которые сложнее просто SELECT
- авторизацией, проверкой прав на рутинги, JWT
- асинхронностью
- Swagger

то хватит более чем, возьмут и без знания фронта или по крайней мере с минимальным знанием (например, bootstrap + jquery).

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

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

Есть 2 основных подхода для решения проблемы изоляции имен в модулях:
- подход webpack до 4 версии включительно - завернуть каждый исходный модуль в свою функцию и переложить эту задачу на средства языка js;
- подход rollup и последователей типа vite - произвести переименование сущностей так, чтоб разные сущности из разных модулей названные одинаково назывались по разному, а одни и те же сущности названные по разному в разных модулей назывались одинаково.

У каждого из подходов есть свои плюсы и минусы.
В подходе webpack с одной стороны получается очень надежная изоляция, так как работают средства самого языка, но с другой на выходе получается больше кода, так как добавляются обертки + некий рантайм для взаимодействия виртуальных модулей. Так же такой код хуже оптимизируется на постобработке, так как тулзы вроде terser банально не могут восстановить связи между разными модулями. Хотя тот же рантайм позволяет гибко разбивать код на чанки и эмулировать динамические импорты.
В подходе rollup возможны ошибки на промежуточной обработке (сам rollup предусматривает большинство из них, а вот плагины могут накосячить, особенно на больших проектах), зато нет дополнительного кода и тулзы вроде terser могут обрабатывать весь бандл целиком со всеми межмодульными связями, а значит делать более эффективные оптимизации.

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

P.S. сделайте небольшой проект из примерно 10 модулей, соберите его webpack/rollup в dev режиме и посмотрите что получается на выходе, очень многое станет понятно, если просто почитать код получившегося бандла.

Потому что вы и не обрабатываете ошибку. Оберните вызов метода await getUser() в try catch.

const fakeUrl = 'https://api.github.co'

function getUser(url) {
  return new Promise((resolve, reject) => {
  	fetch(url).then(data => resolve(data.json())).catch(err => reject(err))
  })
}

const app = async () => {
  try {
  	const result = await getUser(fakeUrl)
  	console.log(result)
  } catch (error) {
  	console.log('error', error)
  }
  
  console.log('end')
}

app()

Typescript compiler - это инструмент проверки типов и компиляции typescript в javascript. Так же он умеет транспайлить конструкции новых стандартов js в более старые стандарты, но это не основная задача этого инструмента, и делает он это хуже целевых инструментов, в частности его можно настроить только на конкретный стандарт.

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

В экосистеме babel есть preset-env нацеленный именно на транспиляцию более новых стандартов в более старые. Его особенностью является поддержка browserlist и подключения только тех плагинов, которые нужны для указанных браузеров. За счет этого получается более оптимальный js на выходе, так как многие фичи после транспайлинга работают медленнее чем нативные и занимают больше кода.

Еще в экосистеме babel есть preset-typescript, который включает поддержку ts синтаксиса и транспиляцию ts в js. При этом, в отличии от tsc, он не делает проверку типов, а некоторые сущности может обрабатывать неправильно (как и большинство сторонних компиляторов ts, т.к. у ts нет строгой спеки и единственным источником правды является код tsc, который далек от идеального).

Оптимальным по выходному результату (пусть и за счет времени сборки) будет вариант, когда сначала ts код обрабатывается через tsc без транспиляции в старые стандарты, а затем происходит транспиляция с помощью babel + preset-env + browserlist.

Зачастую, когда используется связка babel + typescript, то typescript выступает как typecheck инструмент. То есть, typescript ничего не компилит, а просто проверяет типы (через какой-нибудь fork-ts-checker-webpack-plugin).

А бабел уже имеет плагины, которые затем транслируют синтаксис typescript в js.

Вики по GOPATH.
GOPATH подход устарел и с 1.16 версии по умолчанию используются модули.

Если вам так нужен проект в GOPATH, то можно отключить модули:
GO111MODULE=off go get github.com/go-chi/chi/v2

В режиме модулей зависимости сохраняются в кэше.
Их можно перенести в проект командой go mod vendor, и зависимости перенесутся в папку vendor рядом с файлом go.mod.

При сборке проекта зависимости автоматически скачиваются в кэш.

Попробуйте сделать дамп так:

pg_dump -U postgres -W -E UTF8 -d dbname -f dbname.sql

т.к. возможно глючит перенаправление

Если кто то столкнется с этой проблемой, то эта ошибка из-за ассинхронной функции request(), эта ошибка возникала при быстром переключении навигации, при медленном ошибки не возникает из-за успевание срабатывания функции request(), теперь опишу последовательность:
В компоненте сперва вызывается метод componentDidMount в нем есть ассинхронный request(), после происходит componentWillUnmount() затем происходит исполнение ассинхронного request() в нем вызывается this.setState которого уже нет! т.к компонент размонтирован. Во и все))
Можно решить эту ошибку с помощью переменной в которой хранить - логическое значение формирование компонента:

constructor() {
    super();

    this.state = { 
      blogItems: []
    };
    this._isMounted = false;
  }

  componentDidMount() {
    this._isMounted = true;

    request(GRAPHCMS_ENDPOINT, query).then(data => {
      if (this._isMounted) {
        this.setState({
          blogItems: data.blogListses
        });
      }
    });
  }

  componentWillUnmount() {
    this._isMounted = false;
  }

Всё работает, ищи ошибку в другом месте:

Отключите все диски кроме нужного ссд.
Поставьте систему. Должно помочь

Для начала нужно определить для себя две большие разницы как-грится.
Что сейчас на ум пришло
1. есть нативные языки типа свифта, в которых толком верстки, близкой к вебу, нет и в помине
2. есть вариант Apache Cordova, PhoneGap - это фреймворки, позволяющие использовать веб-вью, т.е. показывающие обычную верстку в окошке "реального" приложения (чем-то напоминает PWA).
3. есть react native - фреймворк, ипользующий для бизнес-логики реакте (то бишь js), но визуальную часть и все взаимодействия с железом реализующий через нативные прокладки (т.е. написанные на языке, родном для оси). Из плюсов - можно делать сразу под андроид и под iOS, верстать очень похоже типа как для веба (не очень много "ньюансов"), из минусов - как только нативная библиотека скажет "нимагу", то вы попали :)
4. Ну и есть собственно PWA (Progressive Web Applications) приложения.

Везде свои нюансы, особенности и подводные камни. Бесплатный сыр, знаете ли...

В принципе - фронт-разработчику можно попробовать мобилки, но не следует ожидать предсказуемости и быстрого результата, особенно по началу.