Михаил Р.

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Это происходит потому, что в JavaScript массивы и объекты являются ссылочными типами данных, а не примитивными. Когда вы создаете массив key и добавляете его в Map, вы сохраняете ссылку на этот массив в качестве ключа. При попытке получить значение из Map по ключу [1, 2], вы создаете новый массив [1, 2], который уже не равен массиву key, сохраненному в Map. Поэтому вы получаете
undefined. Верно объяснил?

Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
Под каждый класс нужна отдельная таблица.
Как определить какие взаимоотношения между этими классами?
Нужно примерить следующие коммутативные гипотезы:
Первая пара гипотез:
"Один пользователь должен (может) иметь только одну роль."
"Одна роль должна (может) быть назначена многим пользователям."
Вторая пара гипотез:
"Один пользователь должен (может) иметь несколько ролей."
"Одна роль должна (может) быть назначена многим пользователям."
Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.

Как вообще задавать фикс значения используя бутстрап?

Никак, он не для этого.

Создавать свой класс? Нормально ли вообще создавать свой класс и юзать его в перемешку с версткой на bootstrap?

Да, создавать, да, нормально.

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

Добавляете файл /assets/css/style.css, подключаете после бутстрап.

Так ведь есть-же опция изменения заголовка --header, воспользуйтесь.
То бишь

curl --header "Host: sample-host-name.org" "http://1.2.3.4/index.html"

Посмотрите на highscalability.com/blog/category/example - там есть разбор реальных архитектур. Tilda там нет, но есть например Wix - правда в эпоху до Docker. Но принципы те же.

1. Из коробки компилируется в единственный, сравнительно компактный, бинарь без зависимостей от рантайма и окружения.
(и без подводных, в отличие от full aot и assembly trimming)

2. Сможешь рассматривать вакансии, где требуется Golang, если собираешься искать работу.
3. Сможешь нанимать go-шников со всеми вытекающими, если будешь искать разрабов в свой проект.
4. Если твой проект должен будет активно взаимодействовать, например, с kubernetes и прочими devops-штуками, то Go может быть чуть удобнее, тк практически все эти инструменты написаны на Go и для работы с ними имеются готовые библиотеки, которые, вероятно, будут лучше, чем их альтернативы для .NET.