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 и поделюсь с вами впечатлениями.



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

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

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

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

Ну и где фреймворки для Го? Это язык не для сайтов, а для инфраструктуры. Вот если ты гугл с тыщами сервисов и миллионом индусов, то го огого. Иначе это просто карго-культ. Потому что язык дико неудобный для бэкенда с бизнес-логикой. Раст это вовсе анекдот ходячий. На нем долго и муторно пишется абсолютно всё. В этом смысле он весьма универсален, да.

anonymous
()

Тебе точно нужен комплект Java+SpringBoot. По всем требованиям подходит.

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

А потом рождаются реализации динамической типизации на статике, ага. Если до мозга доберётся, то и динамики на динамике.

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

Давно знал, там это нужно для performance critical задач а также для интеграции сишных библиотек. Но кресты, сильно обмазанные шаблонами, и кресты для вызова их из других ЯП - это небо и земля, как js и ts.

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

А потом рождаются реализации динамической типизации на статике, ага

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

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

Культи тоже так умеют. Но это для специфических задач. Не подходит когда нужен классический сайт.

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

В жаваскрипте такая система типов (если это можно назвать системой), что без чекера будет тяжело. Ну и typescript не такой уж строгий, можно местами забить на типы, и проаннотировать позже, когда все устаканится. А еще можно его вообще не использовать, а делать как обычно на коленке. В жаве вот такой опции нет. Все батарейки ноды были сделаны на динамике, и ниче, взлетело. Как и пхп, и рельсы.

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

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

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

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

А то, что ide че-то там подсказывает - так это не аргумент - разве только для нубья

Проблемы с типами на всяких js/python уже лет 5 не встречал, это нужно специально как-то писать, чтобы были баги по этой части и т.п.

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

не даром последний писк и стандарт - автоматический вывод типов

Который развит только в статических ЯП. Scala, Haskell и конечно, кресты. На Boost.Hana невозможно нормально писать без вывода типов. А using позволяет не писать километровые типы когда auto слишком всё сокращает. На современных крестах можно вообще не указывать типы - вывод типов порешает, ide в растерянности обругают, компилятор соберёт.

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

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

Чекеры в js? Это как нужно НЕ читать (или не иметь) документацию по своим / vendor либам? Плюс в рантайме легко проверить все объекты на типы, если ты не любишь лазить в исходники

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

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

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

Который развит только в статических ЯП

Статический вывод типов развит только в статических языках? Эээ, а он что, должен быть развит в динамических? Типа автоматический вывод типов в динамически типизированном языке? Лол. Так динамический язык и так основан на автоматическом выводе типа, о какой статике может идти речь? В питоне, к примеру, строгая типизация, а в js - нет, разве что это может быть причиной багов

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

Ковыряться в отладчике вместо «пара кликов в иде - смотрим апи типа» - это мазохизм, а не быстрая реализация задачи. Если что, PyCharm вполне умеет в немазохистский вариант.

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

Во-первых, не попытка, а таки полноценный фикс.

Во-вторых, написать алгоритм можно на любом высокоуровневом языке за примерно одинаковое время (нет, плюсы — нифига не высокоуровневый язык). А вот дальше… Real-life story: у нас на работе возникла задача — для унификации логики нужно числовые айдишники везде переправить на строковые. Бэкендеры в лице меня сказали «не вопрос, за несколько часов сделаем; отлаживать не надо, там как только скомпилится — сразу и заработает». Фронтендеры почесали репу и сказали «ну, если выделить специального человека на эту задачу, недели через две он, может быть, справится».

Это я к тому, что кроме написания кода есть ещё и рефакторинг — и вот тут динамическая типизация показывает, какое она днище.

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

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

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

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

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

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

Смотреть апи типа надо в документации. А те, кто её читать не любит - будут читать исходники. А то, что ты описываешь - так кодят в Visual Studio, я такое пару раз на галерах встречал, где люди не понимали что пишут, но пишут и на ходу узнают что пишут что-то лапшеподобное

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

Да чего там делать-то?

    sealed trait Term {
      def apply(argument: Term): Term = throw new Exception("Can't apply")
    }
    case class TInt(value: Int) extends Term
    case class TFloat(value: Float) extends Term
    case class TFunction(value: Term => Term) extends Term {
      def apply(argument: Term): Term = value(argument)
    }
Ну, это так, навскидку. Больше фич — больше кода, само собой.

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

Просто это всё костыли, как и в питоне 3 «типа типизация», не подходит вам js с его прототипами и динамикой, давай делать из него C#

Вы самую фишку js и не используете. А тупо используете js как платформу (браузер) для запуска приложухи написанной на «C# для веб»

Ты только вдумайся - они тащат C# в браузер, нахера? А потом плачем, что всё тормозит и жрёт по 8 гигов памяти

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

Проблемы с типами на всяких js/python уже лет 5 не встречал, это нужно специально как-то писать, чтобы были баги по этой части и т.п.

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

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

Ты выбираешь написать в одну морду веб приложуху. Ты что, будешь писать её в 2 раза дольше, но с типами, нежели в 2 раза быстрее, но без типов? В любом случае ты будешь пускать половину своего кода на js платформе, где статики твоей нет

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

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

Это да, больше решает апи используемых библиотек.

нет, плюсы — нифига не высокоуровневый язык

Плюсы плюсам рознь. Между легаси и современными фичами разница как между разными jvm языками.

Это я к тому, что кроме написания кода есть ещё и рефакторинг — и вот тут динамическая типизация показывает, какое она днище.

В целом да. PyCharm много угадывает и помогает, но свою маму - идею никогда не догонит.

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

Менять одного инвалида на другого? Зачем?

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

Всё. Я нашёл тебе серебрянную пулю. Nodejs с типами - это Dart. Хочешь - пиши на типах, хочешь - на ходу типы выведутся как в js

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

К сожалению, плюсы так изначально задизайнены, чтобы любые абстракции текли.

На самом деле, что реально ускоряет написание кода — это автоматическое управление памятью.

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

Вот пусть процессор и пишет за тебя этот код

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

В питоне, к примеру, строгая типизация, а в js - нет, разве что это может быть причиной багов

Баги везде. Только в питоне они легко локализуются, а в жс задолбаешься искать. Баг вроде есть, но его как бы нет. Потому люди из другой культуры на это посмотрели с недоумением и сделали тайпскрипт. Чтобы хоть как-то сохранить рассудок. А тем, кто вырос на перле и пхп, это норм.

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

Зато питон падает с длинным баг-трейсом и тютю твоему приложению, а JS - нет. JS и дальше будет работать «по скрипту» (как запланированно) в 99% случаев

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

Если у тебя 30 кодеров, и все пишут свои абстракции, каждый тащит себе любимому свой набор либ на js, то да, typescript вам в помощь

Тут человек в одну морду писать хочет. Нафиг ему TS?

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

Когда начинаешь думать об автоматике, то понимаешь, что пора в 2020 переходить на всякие Swift, Nim, D, Rust, Go

Go идеален для целей тс - писать бек быстро и с типами, ну, или Dart

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

Go изначально делали для того, чтобы плохие программисты могли хоть что-то написать. Оно, конечно, не так плохо, как могло бы быть, но и далеко не супер.

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

Он хочет чудо фреймворк для крестов, чтобы был заточен под веб как джанга и можно молодёжно std=c++20

И такой фреймворк есть - это Node.js 😂

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

Всегда больше думают, чем набирают на клавиатуре. «В 2 раза» это вообще от фонаря. И на js не половина кода, а зависит от ТЗ.

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

Тут человек в одну морду писать хочет. Нафиг ему TS?

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

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

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

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

Ну человек хочет батареек, у раста их уже есть, а у nim с библиотеками пока что проблемно (да, по меркам раста, сравнивать с JS и питонами вообще смысла нет).

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

Сам просил.

<trolling>

Самый сложный фронтенд в мире и так уже пишется на крестах благодаря wasm. Примеры - Twitch, тяжёлые игры, работающие в браузере (Unreal Engine, Unity, Godot).

А на том же three.js не такие масштабные проекты.

</trolling>

arturianec100
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.