LINUX.ORG.RU
Форум — Web-development  

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

 , ,


0

2

Хотелось бы услышать ваше мнение.

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

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

  1. полностью переписываем backend
  2. полностью переписываем API, полностью переписываем backend и переписываем frontend под новое API

Положим идем по второму варианту. Создаем тупое API.

Что же отнимает основное время при разработке backend?

  1. Даже если API тупое его все равно нужно документировать и желательно быстро

  2. Взаимодействие backend с хранилищем данных - значит нам нужен какой то ORM, возможно даже не SQL

  3. Реализация backend API, роутинга - можно например использовать REST, swagger и генерировать их из swagger

  4. Тупой язык для backend чтобы при написании на нем думать о логике которую нужно реализовать в функции а не о особенностях языка (как бы легко вы не писали на C например но все равно на php думаешь о языке меньше)

Какие у вас предложения? REST? JsonRPC, grpc? php, python, nodejs? какой ORM? какой фреймворк? какие инструменты? в какой последовательности вы бы все это делали? что даст максимальную скорость разработки от требований до работающего backend? куда копать?

Заранее спасибо за ответы.

★★

Ответ на: комментарий от vvn_black

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

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

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

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

quester ★★
() автор топика

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

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

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

mydibyje ★★★
()
Последнее исправление: mydibyje (всего исправлений: 1)

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

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

bread ★
()

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

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

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

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

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

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

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

Enthusiast ★★
()

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

vbr ★★★
()

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

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

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

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

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

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

H3
()
Ответ на: комментарий от DumLemming

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

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

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

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

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

Toxo2 ★★★★
()

Зависит от проекта, если мне надо сделать что то быстро, я выбираю 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>
...
Чем писать контроллер на бекенде, делать фронт на vue, react и там использовать fetch итд.

MOPKOBKA ★★★★
()
Последнее исправление: MOPKOBKA (всего исправлений: 2)
Ответ на: комментарий от annulen

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

Toxo2 ★★★★
()

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

java+spring+spring jpa

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

untitl3d ★
()
Последнее исправление: untitl3d (всего исправлений: 1)
Ответ на: комментарий от quester

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от emorozov

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

untitl3d ★
()

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

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

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

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)
Web-development