Как и на чем быстрее всего создать прототип web backend?

На чём

На том, на чём есть опыт.

Как

Используя 1000 + 1 фреймворк на том, на чём есть опыт.

Пишите всё в БД.

backend/frontend легко меняются, когда всё приложение в БД, а остальное просто бантики вокруг.

замокай апи! как-нибудь так: https://keyholesoftware.com/2020/03/16/mock-restful-server-fast-with-json-server/

Плюсану, для MVP можно всё запилить и на Firebase и на любом GraphQl Engine у которого БД в бэке автоматом.

На том, на чём есть опыт.

Тот кому это нужно наймет того кто будет писать backend, вопрос кого нанимать и с помощью чего и как создавать

Используя 1000 + 1 фреймворк на том,

Нужно больше конкретики, об этом топик

Похоже на вопрос, чего бы такого в гараже собрать, чтобы потом эппл по капитализации догнать.

совершенно не похоже, про бизнес идеи тут нет вопроса

Меньше всего об особенностях думаешь в рубях, кмк. В любом случае согласно вашему вопросу вам нужен отзыв человека который делал коммерческий бэк на каждом из перечисленных вами ЯП а значит знает три-четыре ЯП для бэка в совершенстве включая либы и фреймворки внутри экосистем этих ЯП, чтобы иметь возможность их сравнивать по time to market, таких людей я не знаю. Поэтому пишут на том что знают, либо на том что популярно на рынке.

что даст максимальную скорость разработки от требований до работающего backend?

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

нужно сделать backend из говна и палок - главное максимально быстро

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

Какие у вас предложения?

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

2. Обмениваться данными между Интернет-страницей и серверной частью ПО лучше в текстовом виде для упрощения отладки, то есть используем REST API.

3. В джававском коде для обработки «рестовых» запросов и выдачи содержимого Интернет-страницы в целом я бы использовал простые сервлеты, чтобы не тащить лишнего в код, например, «Спринг».

4. Чтобы не вникать в язык запросов баз данных я бы использовал «Хайбернейт», потому как с ним справится даже «продвинутый» школьник ибо творческого мышления в этом умении не требуется, нужно лишь повторять написанное в руководстве «Хайбернейта».

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

Желаю успеха!

Я бы писал на го без всяких орм. Возможно OpenAPI предварительно и из него сгенерировать интерфейсы. Фронт на реакте. А спешить некуда. Тише едешь дальше будешь.

Взять Python + FastAPI, конечно же.

OpenAPI-документация генерируется из кода на лету и всегда актуальна.

Полно драйверов для работы с различными СУБД, синхронные и асинхронные.

И в целом код на Python содержит минимум boilerplate’а и максимум бизнес-логики.

Пишите всё в БД

И лишайте себя нормальной отладки и версионирования кода.

А потом нужно базу менять и жопа. Если tsql какую хотелку не вывезет - тоже жопа

И лишайте себя нормальной отладки и версионирования кода.

Ну, можно предположить что там источник скуль скрипты а база каждый раз создаётся

А потом нужно базу менять и жопа.

Не могу придумать сценария, когда именно «нужно» менять Postgres на что-нибудь.

Бывают приключения при переходе с версии на версию. Как с табличными функциями было при 9.6->10.0. Но это ж не жопа, так, жопка.

Питоны-жсы-го уж куда более подвижны в сторону разных жоп, ИМХО.

Тыкал вот на днях в asyncpg. Презабавно там оказывается оно работает с json на входе в процедуры ПГ. Да и в целом - с процедурами ПГ с одинаковыми именами, но разными параметрами все языки без типизации забавные.

Не могу придумать сценария, когда именно «нужно» менять Postgres на что-нибудь.

Ну вот в Убере придумали: https://www.uber.com/en-GB/blog/postgres-to-mysql-migration/

Зависит от проекта, если мне надо сделать что то быстро, я выбираю jquery, php, mysql + phpmyadmin и открываю удаленную FTP папку на хостинге, и редактирую файл в notepad.exe

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

<?
global $db;
$res = mysqli_query($db, 'SELECT * FROM `ITEMS`');
$dbItems = mysli_fetch_all($res, MYSQLI_ASSOC);
?>

...
<ul>
  <? foreach ($dbItems as $item): ?>
    <li><?= $item['NAME'] ?></li>
  <? endforeach ?>
</ul>
...

Насколько я понял - красавцы в Убере. Обосновано наваляли в 2016 году. ПГшники отреагировали правками. Так оно и должно быть, по идее в Open Source. Наверное.

питон и фастапи

Тут уже написали, повторю для весомости аргументов, а так же подтвержу имея личный опыт овер 10 лет в этой сфере:

java+spring+spring jpa

В свете последних событий с golang лучше не связываться, а python имеет тенденцию скоро уйти в небытие.

Найти толкового исполнителя, и пусть сам выбирает технологии. Я бы, например, писал на перле.

Тот кому это нужно наймет того кто будет писать backend, вопрос кого нанимать и с помощью чего и как создавать

Ну так ты сначала человека найди, а потом уже пусть он пишет на чём умеет.

LOL. Это Java уходит в небытие, фактически, КОБОЛ 2.0.

Django

Поскорее бы. Я узнал сколько зарабатывают программисты на коболе и как их перевозят в страны первого мира (что бы это ни значило) с полным релок пакетом.

В Netbeans.

Если MVP создан и бизнес гипотеза верна то далее возможны только два варианта

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

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