Everything_is_not_so_bad

Просто хранить на жёстких дисках - неудобно и не сильно надёжно.
Для кого разрабатывали ceph, minio, Gridfs, riakcs, etc?

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

Если нужен самый простой вариант, то да, как верно выразились выше: JSON.

Ещё можно взять BSON, или Msgpack. Они будут эффективнее, но сложнее для отладки.

Ещё, в в качестве самого корректного варианта я бы предложил Protobuf. Но стоит учитывать, что он сложнее описанных выше вариантов.

Гуглите docker compose, Link

https://ruby-doc.org/stdlib-2.6.1/libdoc/csv/rdoc/...

весьма мощный сервер (8gb

Дааааа? А я думал дохленькая виртуалочка. Довольно средние железки на 256гб тогда что?

На тяжелые запросы не грешу, т.к., во-первых, билд запросов на 100% отдан ORM (Eloquent, Lumen), и возможность кривыми руками написать какой-нибудь count(*) сведена к нулю

Ха. Хахахаха. Хорошая шутка.
Самый лютый бред вместо запросов делают именно ORM.

Выкручивать настройки логирования, в момент проблемы смотреть хотя бы вот это: https://github.com/dataegret/pg-utils/blob/master/...
Ставить какой-то мониторинг, умеющий мониторить базу.
И смотреть что именно делает база и чем занято железо в момент проблемы. Особенно I/O. process title бы хоть сохранили/написали. Там и то продублирован command tag.

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

И на php (phpreact) можно написать приложение, обрабатывающее 10к запросов в секунду на одном процессоре, а можно на nodejs (javascript) написать асинхронное приложение, которое штатным распаковщиком gzip будет тратить 99% времени на распаковку gzip а потом оставшуюся половину на копирование массива с данными (из-за чего скорость на порядок ниже php получается, реальный пример простой обработки БОЛЬШОГО количества упакованных текстовых дампов)

Если же у вас проблемы создает обработка данных, пишите критичные вещи на c++ и подключайте модулем.

Во-первых, язык влияет на производительность программистов, а не программ. Узким местом может стать платформа, в вашем случае виртуальная машина CPython. Но при разработке сетевого ПО в целом и web-приложений в частности главный тормоз - это ввод/вывод. Издержки на него на порядки превосходят издержки на интерпретацию, так что последняя практически не влияет на производительность. В то же время CPython хорошо справляется с вводом/выводом с помощью Asyncio и способен решать проблему c10k.

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

Почему сразу не в блокноте резать?
Если по сути вот
ffmpeg -ss 00:00:30.00 -t 25 -i bar.mp3 -acodec copy bar-new.mp3
режет с любой точностью любой файл который скормишь, даже видео

graphql это решает как бы,
Rest не единственная возможность общения клиент-сервер

Все мои аргументы, в том числе, что JS априори медленнее Go и не поддерживает многопоточность, нет нормального ООП, и что не надо клиента грузить тоннами JS ради full AJAX, и вообще разработку станет вести легче и быстрее они оспаривают.

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

Ибо основные задержки не зависят от языка - это сеть и СУБД (и пр. связанные с дисками операции).

Впрочем, при нагрузке сервера очень большим числом клиентов и/или при очень сложной логике обработки (но не связанной с СУБД/дисками, а завязанной только на процессор) - скорость языка значение уже имеет.

У вас - как? В чем именно узкое место?

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

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

и что не надо клиента грузить тоннами JS ради full AJAX

При несложной логике - да.
При сложной логике - не все так очевидно.

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

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

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

Что можно сделать:
- определить реальные проблемы
- определить критерии их решения (скорость, размер, page speed и так далее)
- определить время за которое команда готова оптимизировать ангулярное приложение до нужных параметров

Если не сделают - поднять вопрос еще раз, показав свой вариант.

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

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