Eugene Usachev

Абсолютно так же как и остальными Node.JS, Go и другими языками в современном мире пакуется в контейнер и деплоится в прод. Есть несколько готовых вариантов, но все они будут придерживаться docker и docker compose:

- ручное: Клонируем репозиторий, билдим на этом сервере docker compose build && docker compose up -d.
- ручное: Локально билдим докер образ и пушим в регистр докера, на самой машине так же docker compose pull && docker compose up -d но уже только с получением образа из регистра докера в docker compose.
- полу-автоматически: Пишем .sh скрипт который на git хуки или руками будет делать действия что и в одном из предыдущих вариантов, но без Workflow.
- автоматически: Используем GitLab/Github Workflow или любой другой, на каждый релиз/коммит/PR запускаем Workflow с билдом, дальше пушит полученный контейнер в регистр, затем последним этапом будет подключение по SSH к серверу и применения условного

cd /path/to && docker compose pull && docker compose up -d

Я привёл самые простые варианты. Ещё есть варианты с k8s, ansible и другими вещами, но это не ваш случай судя по всему.

1. async-await используй
2. Используй какую-нибудь orm-ку (EF core, Dapper, linq2db). Многие из них как правило явно запрещают параллельные запросы в рамках одной транзакции.

Но вроде чисто в теории sqlite разрешает конкурентное чтение (но не запись)

ну, раз никто не ответил, чуток лекции от меня

во-первых как сказал ув. Василий Банников -тестировать надо только IO диска
вот это вот детский сад, так нельзя

Сначала я прогнал тест на Windows... я и не стал проверять на Windows неделю назад (работал в Docker).

условия должны быть неизменны

во-вторых, как говорю я - надо изучить что уже известно по этому вопросу:

• вот тут товарищи тоже задаются года с 2018
  
• а вот и кое-какой продукт
  

да, это про IO а не файлы, но - с твоей задачей где-то рядом, если вообще не то что надо , но там много вопросов - ответов, которые расширят твое понимание - например, разное поведение в разных ОС

в третьих, есть такая штука как кеш диска (а еще есть кеш у харварного рейда, но не всегда), да так что в этой вашей команде DD
dd if=/tmp/test.img of=/dev/null bs=1M count=1024
есть спец опция для отклбчения кеша, иначе получается космик цифры

в четвертых - есть проблема храннеия мелких файлов и вообще файловой системы, тут приведу только два-три слова: самопис ( там почитаешь про суть проблемы), пром1 пром2

в общем, задачка сильно посложнее чем просто погонять байты
и, это конечно не мое дело - но "а зачем"? что ты будешь делать с полученной инфой?

если все же "а зачем" осталось актуальным - я бы делал так:
1) прогнал прогу для дисков из пример выше
2) посмотрел бы вдумчиво это видео (увы, не про Rust, но докладчик знает толк в извращениях (с)), в том числе и ввиду твоих проблем с генерацией в памяти

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

На торренты можно выложить или в свой телеграм канал. А потом ходи и надоедай всем со своей игрой :)
Надеюсь там можно "грабить корованы".

Вы пытаетесь сравнить тёплое с мягким.

rest - архитектурный подход.
Axios - библиотека для отправки http запросов.
Babel - транспайлер.
Webpack - сборщик/бандлер.

Каким боком тут сервер и питон я не понял, тк всё перечисленное работает в браузере.

Ты забыл третий вариант, самый быстрый и наиболее предпочтительный если общее количество опций не велико (сотни, например у mysql лимит 1024 колонок максимум) - каждая опция это своя колонка, пустое (null) значение будет значить отсутствие опции у записи.

Недостаток подхода - если у объекта может быть несколько опций с одним именем, то такой подход не работает (но судя по всему это не твой случай).

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

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

p.s. если говорить про твои варианты:
* для 1 используй json сериализацию (опция=значение) в mysql для работы с такими данными есть соответствующие методы
* для 2 постарайся вместо текстовых наименований опций использовать числовые идентификаторы, заведя соответствующий классификатор либо в базе в отдельной таблице либо в виде констант в коде.

p.p.s. Ну и еще вариант, если тип значений опций - boolean (либо ограничен небольшим количеством значений, например цвет светофора 4 - выключен, красный, желтый, зеленый) то так же заводи для этих значений числовой эквивалент. В этом случае у тебя появляется еще бонус, упаковывать битовые значения (где количество вариантов 2^x и x это количество бит) и хранить в целочисленном поле сразу несколько (правда не все базы позволяют индексировать операции с битами).

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

Какую конкретно? Ту, которую лучше знаешь, если не можешь назвать конкретную причину, почему лучше изучить другую и взять другую. Например вот я беру postgres по-умолчанию, но вот у меня проект, который требует минимального жора ресурсов и наиболее простой инфраструктуры - тогда беру sqlite.
Или наоборот - я понимаю, что у меня какие-то специфичные требования по консистентности и доступности, система у меня будет распределённая, а запросы у меня будут исключительно key-value, да и желательно ещё иметь возможность подписки на изменения каких-то ключей - тогда беру etcd.

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

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

Ну раз с фронта пересели, то аналогию понять должны: В чëм отличие Google Chrome от JavaScript?

nginx — это реверс-прокси
go — это яп.

в чём вопрос-то?

то как go может работать на ngnix?

nginx проксирует запрос в сервер на го, который пишет программист. Цепочка проксей может быть сколько угодно большой. Ты можешь поставить nginx -> nginx -> caddy -> nginx -> gin, никто не запрещает.