LINUX.ORG.RU

Посоветуйте асинхронный бэкенд

 , , ,


2

7

Пишу в dev, а не web-dev потому, что C++ и другие якобы «не вэб языки» здесь в тему.

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

Есть некоторый опыт и хорошие впечатления от Django.

Нужны:

  • Хорошая производительность
  • Асинхронщина для любого IO а-ля нода
  • Выразительный ЯП со СТАТИЧЕСКОЙ типизацией
  • Хорошая документация и немаленькое сообщество (не просто API Reference, а ещё и Tutorials) и чтобы фреймворко-специфичные проблемы легко гуглились
  • Много батареек, как в джанге, обязательна ORM
  • И REST API, и Server Side Rendering // решил отказаться
  • Всякие Light, zero-dependency и embedded мне безразличны // но рассматривались тоже
  • Удобная работа с WebSocket // да, этот пункт я дописал гораздо позже

Лучше советовать не «язык Х» а «язык Х + фреймворк Y».

Также меня царь образумил в том смысле, чтобы делать SPA вместо server side rendering. Ведь перерисовывать ВСЁ по нажатию кнопки - это же антипаттерн отзывчивого интерфейса. Плюс везде, где можно заменю http на websocket - вместо целой страницы по тормозному хттп всего лишь небольшой json по шустрому вебсокету - это сильная разгрузка bottleneck’а на клиенте - обмен данными по сети.

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

UPD Решил брать NestJS + React + MobX. Если по ходу дела откажусь, то буду рассматривать Dart + Flutter, Scala + Play, Java/Kotlin + Spring/Boot.

В будущем обязательно поэксперементирую и запилю сайт крупнее хелловорлда на C++ и Rust и поделюсь с вами впечатлениями.

Какая принципиальная разница - фрейм на культях или нет?

O_o

Но, наверное, это просто потому что библиотека с кучей батареек. В сях/плюсах же всё вообще плохо с зависимостями.

А так, подпишусь.

intelfx ★★★★★ ()

Всякие Light, zero-dependency и embedded мне безразличны
Хорошая документация и немаленькое сообщество (не просто API Reference, а ещё и Tutorials) и чтобы фреймворко-специфичные проблемы легко гуглились
Много батареек, как в джанге, обязательна ORM
И REST API, и Server Side Rendering
На примете Node.js + Express + TypeScript. Или же связка Express + TypeScript не имеет смысла?

В web-dev.

/thread

LamerOk ★★★★★ ()

Есть некоторый опыт и хорошие впечатления от Django

Почему бы не отказать от «со СТАТИЧЕСКОЙ типизацией» и не закрепить хорошие впечатления?

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

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

arturianec100 ()
Ответ на: комментарий от MOPKOBKA

Это полная противоположность «нужно много батареек». Мне нужно не голые байты перекладывать с закатыванием мира вручную, а условный User.register(payload). Мне фреймворк, а не сервер.

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

У тебя очень противоречивый список требований. Например, популярный полнофункциональный фреймворк с большим сообществом сужает варианты радикально, и уж точно C++ там близко не лежал. Но ниже ты приводишь Express, а это не совсем фреймворк, а скорее совсем не фреймворк. Ну точно не уровня джанго. В общем, хз что тебе надо. Статическая типизация для одиночки как собаке пятая нога, особенно на начальном этапе. Асинхронность тоже слишком переоценена, тем более такая тупорылая как в ноде. По отдельности все твои хотелки еще можно рассмотреть, а вот вместе не складывается.

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

Неужели «популярный полнофункциональный фреймворк с большим сообществом» + асинхронность + статическая типизация = специфические требования? В том же фронтенде это адекватные требования!

arturianec100 ()

Самое большое сообщество, наверное, вокруг Boost.Beast-а. Но, наверное, Boost.Beast самый низкоуровневый из всех.

Да и батареек в плюсовых фреймворках вряд ли много. Все-таки на C++ такие фреймворки не обычной веб-разработки делаются, а для решения специфических задач.

К oat++ вроде бы недавно ORM анонсировали: https://oatpp.io/docs/components/orm/

PS. Ну и на правах рекламы предлагаю глянуть в сторону RESTinio.

eao197 ★★★★★ ()

Ты думал тонко троллить, тогда объясни - нахера тебе СТАТИЧЕСКАЯ типизация на бекенде? Нравится джанга - вот и бери её, у неё только один конкурент - рельсы. Остальные платформы даже рядом не стояли по количеству батареек.

Сайт на С++ - это сразу в дурку

ТС смешал тут в кучу все платформы и хочет поржать, глядя как начнут нахваливать свои болота местные патлатые

menangen ★★★★★ ()
Ответ на: комментарий от baist

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

menangen ★★★★★ ()

Scala/Play/Slick. Асинхронщина получается автоматически, фреймворк требует использовать Future, а Future само по себе работает в отдельном зелёном треде. Полная статика, вывод типов (то есть, белок-истеричек не будет).

Miguel ★★★★★ ()
Ответ на: комментарий от arturianec100

Так Nest бери, какой еще C++, не дуркуй. Короче, реальность такова: если статика на маргинальных языках, то там будет lightweight во все поля (читай поделия с 1.5 разрабами). Если статика на жабке, то будет ЖИР, который хлебают обычно в сотню рыл. У динамиков все намного лучше и с фреймворками, и с сообществом. Сейчас уже и питон, и пхп, и даже руби оснастили тайпчекерами. Проблем с типизацией там нет, с производительностью возможно. Зато производительность разработки высокая. И большие сообщества дают много батареек и информации. А толку от супербыстрого бэкенда на крестах, если ты тупо не сможешь запилить фичу за разумное время?

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

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

th3m3 ★★★★★ ()
Ответ на: комментарий от menangen

тогда объясни - нахера тебе СТАТИЧЕСКАЯ типизация на бекенде

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

Откуда такой хейт к статике? Ведь TypeScript же взлетел.

Сайт на С++ - это сразу в дурку

«Не нужен в странах A, B, C» != «не нужен нигде».

Готов заявить, что всё сообщество вокруг https://github.com/Microsoft/cpprestsdk нужно отправить в дурку? Учитывая, что та же MS запилила кучу веб фреймов на других ЯП.

ТС смешал тут в кучу все платформы

Это же посоветуй-тред. Тут выбор из разных платформ.

arturianec100 ()
Ответ на: комментарий от menangen

Как не выбираю, если сразу написал, что на примете вполне банальная нода? Что за реакция? «На примете нода, подскажите за С++ для этой задачи.» – «Что ты как полоумный носишься со своими крестами???»

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

arturianec100 ()

Есть некоторый опыт и хорошие впечатления от Django.

Ну и что же вас останавливает?

Для pet-проекта я бы выбрал Laravel. Вы же не фейсбук пишете, где c++ это не блаж, а необходимость.

sniper21 ★★★★★ ()
Ответ на: комментарий от arturianec100

Хочешь пописать веб на крестах? Так не коси под дурачка, а бери и пиши расширения для ноды (нода на с++) - апи открытые и всё такое, или ты типа не знал, что можно в ноде свой любой c++/c код прилепить?

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

Мне бы побыстрее начать

https://habr.com/ru/post/212705/

Установи демон broadwayd и запусти его указав порт. И потом запусти любое GTK 3 приложение. зайди с браузера на айпишник или локалхост.

Считай ты получил сайт на С/С++ очень очень быстро!

Кажется там OpenGL не поддерживается единственное.

baist ()
Ответ на: комментарий от menangen

За это придётся заплатить скоростью разработки, не даром последний писк и стандарт - автоматический вывод типов

Гм. Ты прикалываешься? Автоматический вывод типов уже означает, что язык статически-типизированный.

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

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

Самый насыщенный информацией ответ, спасибо.

У динамиков все намного лучше и с фреймворками, и с сообществом

Почему с учётом этой ситуации TypeScript взлетел?

производительность разработки высокая

В моей ситуации это не то, ради чего можно всем жертвовать, в этом аспекте моя ситуация нетипична для вебдева.

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

Depends. Я, когда нанимался на свою последнюю работу, Скалу не знал вообще. Ну, пару хелловорлдов написал. Но тестовое задание сделал, и, по-видимому, достаточно хорошо, учитывая, что меня таки наняли.

Miguel ★★★★★ ()